On Saturday, February 7, 2015 at 11:25:02 AM UTC+8, Harlan Stenn wrote:
> Pretty much the same thing, except with ":config addpeer ..." and
> ":config unconfig ...".
>
> I think...
>
> Please feel free to add examples to:
>
> http://support.ntp.org/Support/MonitoringAndControllingNTP
> http://
Paul writes:
> On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn wrote:
>
> > There are times "repair" is perfectly acceptable, and we do that.
> >
> > There are times "replace" is better, and we do that.
>
> My point is a long drawn-out discussion of changes to the core of ntp seem
> less than prod
On Feb 11, 2015, at 7:23 AM, Rob wrote:
> But I see it has also been explained elsewhere in the thread: ntpd has
> a maximum on the momentary drift of 500ppm, no matter if it is static
> or dynamic or the sum of two. I think that is not warranted.
Do you believe that a clock which loses or gains
On Wed, Feb 11, 2015 at 4:32 PM, Harlan Stenn wrote:
> There are times "repair" is perfectly acceptable, and we do that.
>
> There are times "replace" is better, and we do that.
>
My point is a long drawn-out discussion of changes to the core of ntp seem
less than productive when the announced w
Paul writes:
> On Wed, Feb 11, 2015 at 8:22 AM, brian utterback > wrote:
>
> > But no one who does actively engage really understands
> > it or knows how to improve it. Unruh has a point, we don't know if there
> > isn't a better way built on statistical analysis.
> >
> >
> Since it seems the NTF
On 2015-02-11, Terje Mathisen wrote:
> William Unruh wrote:
>> On 2015-02-11, Harlan Stenn wrote:
>>> William Unruh writes:
On 2015-02-10, Terje Mathisen wrote:
And as far as I can see, 500 or 5000 makes little
difference to the control loop. Yes, it is harder for other systems to
On 2015-02-11, Harlan Stenn wrote:
> William Unruh writes:
>> On 2015-02-11, Harlan Stenn wrote:
>> > It's one thing if a system rarely steps. It's a bit different if those
>> > steps happen more frequently.
>>
>> Yes. And it is either equally rare that the system will go over 500PPM,
>> but so
On 2015-02-11, Jochen Bern wrote:
> On 02/11/2015 10:01 AM, Rob wrote:
>> Terje Mathisen wrote:
>>> The 500 ppm limit is not at all arbitrary!
>>>
>>> In fact, it was originally just 100 ppm, but when too many systems
>>> turned up with a system clock which was a bit too far out, Prof Mills
>>>
Jochen Bern wrote:
> However, I've also seen hardware occasionally flip-flopping from -900 to
> +1100 and back, complete with the developers of the firmware blaming "a
> bug in ntpd" for failure to discipline *that*.
Ok that is different, it is not a static drift.
But I see it has also been expl
On 02/11/2015 10:01 AM, Rob wrote:
> Terje Mathisen wrote:
>> The 500 ppm limit is not at all arbitrary!
>>
>> In fact, it was originally just 100 ppm, but when too many systems
>> turned up with a system clock which was a bit too far out, Prof Mills
>> redid the control loop to allow a 500 ppm
On Wed, Feb 11, 2015 at 8:22 AM, brian utterback wrote:
> But no one who does actively engage really understands
> it or knows how to improve it. Unruh has a point, we don't know if there
> isn't a better way built on statistical analysis.
>
>
Since it seems the NTF "proposal" is to replace rathe
Jan Ceuleers wrote:
I'd like to draw this list's attention to an idea that Reyk Floeter
floated, namely to use TLS to help sanity-check NTP timestamps:
http://marc.info/?l=openbsd-tech&m=142356166731390&w=2
Isn't public/private signed timestamps far better?
If you can't get that, and are too
Harlan Stenn wrote:
catherine.wei1...@gmail.com writes:
The toish is a tool made by our system, the purpose of "toish
setobject cfg.ntp.servers 192.168.1.101" is to change the ntp server.
I've searched and find that the time out error may be related to
ntpdc's deprecation. Since when I change th
William Unruh wrote:
On 2015-02-11, Harlan Stenn wrote:
William Unruh writes:
On 2015-02-10, Terje Mathisen wrote:
And as far as I can see, 500 or 5000 makes little
difference to the control loop. Yes, it is harder for other systems to
follow one with a large drift, but it is even harder to f
On 2/11/2015 2:12 AM, Harlan Stenn wrote:
> William Unruh writes:
>> > On 2015-02-10, Terje Mathisen wrote:
>>> > > William Unruh wrote:
> >> No. It only does that for "offsets from Hades". The Ones from Hell,
> >> ntpd
> >> abandons all hope and quits. ( Hades is 128ms to 1000 se
I'd like to draw this list's attention to an idea that Reyk Floeter
floated, namely to use TLS to help sanity-check NTP timestamps:
http://marc.info/?l=openbsd-tech&m=142356166731390&w=2
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp
catherine.wei1...@gmail.com writes:
> On Wednesday, February 11, 2015 at 3:40:02 PM UTC+8, Harlan Stenn wrote:
> > catherine.wei1...@gmail.com writes:
> > > When I change ntp servers by "toish setobject cfg.ntp.servers 192.168.1.1
> 01"
> > > in linux, ntp server print logs "localhost: timed out,
catherine.wei1...@gmail.com writes:
> On Friday, January 24, 2014 at 9:40:56 PM UTC+8, Steve Kostecke wrote:
> > On 2014-01-24, David Lord wrote:
> >
> > > On NetBSD-6 i386 ntp-dev-4.2.7p410
> > > $ ntpdc -c kern
> > > localhost: timed out, nothing received
> > > ***Request timed out
> > >
> > >
William Unruh writes:
> On 2015-02-11, Harlan Stenn wrote:
> > It's one thing if a system rarely steps. It's a bit different if those
> > steps happen more frequently.
>
> Yes. And it is either equally rare that the system will go over 500PPM,
> but sometimes a computer can have a large "natural
catherine.wei1...@gmail.com writes:
> By the way, I'm using the 4.2.8p1, and when I use the command ntpdc
> -l. It prints out "localhost time out, nothing received". Is this due
> to the depreciating of ntpdc?
See the "mode7" documentation in html/miscopt.html .
H
Terje Mathisen wrote:
> The 500 ppm limit is not at all arbitrary!
>
> In fact, it was originally just 100 ppm, but when too many systems
> turned up with a system clock which was a bit too far out, Prof Mills
> redid the control loop to allow a 500 ppm range.
>
> It could have been a lot more,
On Wednesday, February 11, 2015 at 3:40:02 PM UTC+8, Harlan Stenn wrote:
> catherine.wei1...@gmail.com writes:
> > When I change ntp servers by "toish setobject cfg.ntp.servers
> > 192.168.1.101"
> > in linux, ntp server print logs "localhost: timed out, nothing received",
> > the
> > ntp serve
On Friday, January 24, 2014 at 9:40:56 PM UTC+8, Steve Kostecke wrote:
> On 2014-01-24, David Lord wrote:
>
> > On NetBSD-6 i386 ntp-dev-4.2.7p410
> > $ ntpdc -c kern
> > localhost: timed out, nothing received
> > ***Request timed out
> >
> > Perhaps that is intended behavior for 2014 given recen
On 2015-02-11, Harlan Stenn wrote:
> William Unruh writes:
>> On 2015-02-10, Terje Mathisen wrote:
>> > William Unruh wrote:
>> >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd
>> >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is
>> >> >1000 se
24 matches
Mail list logo
