[ntp:questions] ntpd and database servers

Brian Utterback brian.utterback at sun.com
Wed Jan 20 20:22:20 UTC 2010

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!"

Brian Utterback

More information about the questions mailing list