[ntp:questions] Re: ntpd, boot time, and hot plugging

Richard B. Gilbert rgilbert88 at comcast.net
Sun Feb 6 14:08:39 UTC 2005

Per Hedeland wrote:

>In article <vaKdnSNBMfU2upnfRVn-uQ at comcast.com> "Richard B. Gilbert"
><rgilbert88 at comcast.net> writes:
>>I think maybe what people are looking for, that ntpdate seems to do and 
>>ntpd does not, is:
>>1.  Get the time accurate to within  X seconds quickly.
>>2.  Set that time quickly.  The presumption here is that we are in a 
>>state where it's OK to step the clock; e.g. we are booting and nothing 
>>has started yet that will be upset by a change in time.  Slewing the 
>>clock to correct an offset of, say, 127 milliseconds, to within, say, 5 
>>milliseconds,  will take about 250 seconds and that is unacceptable when 
>>we need to be within 5 milliseconds of the correct time as quickly as 
>>The user may wish to specify the required accuracy, knowing that there 
>>is a trade off with elapsed time to achieve that accuracy.  How good 
>>"good enough" must be will vary.   Someone recording the time workers 
>>started work and the time they stopped may be satisfied with plus/minus 
>>one minute but it's 8:00AM local time and he needs it right now!  
>>Someone else might really need plus/minus ten microseconds and be 
>>willing and able to wait two or three hours to get it.
>This I think is way beyond "what people are looking for" in this
>particular area - and I'm not sure it's very meaningful either: It makes
>no sense to set the time with great accuracy and then just leave it,
>since the clock will quickly drift away. Achieving and *maintaining*
>great accuracy, by calculating and taking the drift into account, is
>precisely what ntpd already does in its normal mode of operation, of
I'm not suggesting that ntpd should set the clock and let it drift!  
Having once set the clock, ntpd would resume normal operation with "good 
enough" values of time and frequency.  An additional minute or two would 
be required to check the clock frequency.  If it takes two minutes and 
the frequency error is less than 500ppm, as it must be if ntpd is to 
work at all, the clock could not drift more than sixty milliseconds in 
two minutes.

If a user elects to use "fast startup" he must understand and accept the 
risks and the fact that it may still take anywhere from several minutes 
to several hours to achieve the best synchronization the system is 
capable of.  I've seen "cold" startups where the time was set by ntpdate 
and no drift file take up to twelve hours to stabilize with offsets 
below 500 microseconds.  The offsets never exceeded twenty milliseconds 
and decreased steadily.

>The goal, whether achieved with a separate program or a special startup
>mode of ntpd, is to "quickly" (5 seconds sounds like a reasonable upper
>bound) set the clock "well enough" that ntpd in normal operation can
>from that point on maintain it without steps. I'm intentionally using
>"goal" rather than "requirement", because with a big clock drift and
>lack of previous knowledge of it (i.e. drift file), the goal may not be
>possible to achieve. In "normal circumstances" it should be no problem
>at all though, and ntpdate does it easily.
>--Per Hedeland
>per at hedeland.org

More information about the questions mailing list