[ntp:questions] ntpd and database servers
unruh at wormhole.physics.ubc.ca
Wed Jan 20 21:47:33 UTC 2010
On 2010-01-20, Brian Utterback <brian.utterback at sun.com> wrote:
> unruh wrote:
>> On 2010-01-15, David Woolley <david at ex.djwhome.demon.invalid> wrote:
>>> unruh wrote:
>>>> Note, chrony, another implimentation of ntp, can adjust the clock much
>>> Although I tend to agree that for most users chrony may behave better
>>> than ntpd, it is a user of the NTP wire formats, but not an
>>> implementation of NTP. Obeying the slew rate limit is necessary before
>>> you can claim to implement NTP, rather than SNTP.
>> Sorry, I do not buy that. The reference implimentation does not honour
>> that limit. It will step the clock, which is an infinite slew rate. And
>> as David Mills himself has said, that 500PPM was a figure hauled off the
>> top of his head-- there is not particular justification for it.
>> The advice is that you adjust your computer's c;lock by hand using the
>> tick adjust so that it
>> is withing 500PPM and then use ntp. All chrony does is to automate that
>> procedure and adjust the tick to bring the system time within 500PPM.
>> So, let me phrase it this way. Chrony impliments the ntp. It also has a
>> mechanism to automatically adjust the system clock tick size to bring it
>> within the ntp 500PPM limit. Does that make you happier?
> You should. While the NTP max slew rate is arbitrary, it is not
> without importance. It creates a maximum boundary of error in the
> frequency adjustment in the downstream clients. While the step does
> violate the strict adherence to the rule, by making the change
> instantaneous the downstream clients will likewise step and will not
> end up with an unbounded incorrect frequency adjustment.
> Of course, this is predicated on the assumption that the system that
> is slewing at the high rate is itself an NTP server. If you wanted to
> accomplish this, then I think that while the high speed slew is
> ongoing, the system should refuse to serve NTP requests. I have
> thought about whether it would be worthwhile to have a status bit that
> when set meant "slewing ongoing, my timestamps are lies!"
But the timestamps are not lies. they are far closer to the real time
than is that serverd by ntpd, and it is time that ntp serves, not slew
rate. ntpd wanders off into the wilderness ( I have seen it go off by
20ms, when its steady state error is 2 usec) with its slewing that those
times are far more lies that the 20usec off but with a slew rate of
700PPM that you might occasionally with chrony. Remember at the fastest
ntp queries once every 16sec. By that time the slew is long finished on
chrony ( but barely started on ntpd). Ie, I simply do not believe what
you are saying here.
> Brian Utterback
More information about the questions