[ntp:questions] Query about NTP accuracy

David Mills mills at udel.edu
Mon May 25 16:21:43 UTC 2009


Richard,

You are completely misrepresentng the facts. We have run a 24x7 shop 
here for 23 years. We occasionally do, as happened last night, lose 
machine room power. Last night our servers came back up after two houes 
without juice within a few milliseconds. One of our servers took ten 
minutes to purge and repopulate the DNS zones, but ntpd had set the time 
in much less time than that.

To say it takes ten hours to synchrnize is totally disengenious. Unless 
tinkered otherwise, the time is forced to within 128 ms at reboot in any 
case and converges with overshoot not greater than six percent within 
one hour. It may indeed take some hours to converge within a millisecond 
or two, but that happens only the first time the daemon is ever started. 
Once the frequency file has trimmed up, the error at reboot determined 
only by the error of the battery backup RTC clock, and that is seldom 
more than a few milliseconds unless the power outage is more than a few 
hours.

We need a litle more truth in advertising here.

Dave

Richard B. Gilbert wrote:

>Garrett Wollman wrote:
>  
>
>>In article <ywn9zld20zs5.fsf at ntp1.isc.org>,
>>Harlan Stenn  <stenn at ntp.org> wrote:
>>
>>    
>>
>>>I agree that ntpd -g is usually better than sntp (or ntpdate) to initially
>>>set the time, but the choice is between "Set the clock well, even if it
>>>takes a little time" and "Set the clock as quickly as possible and it may be
>>>wrong."
>>>      
>>>
>>What is actually needed at boot time is usually neither of these
>>things.  It's more like "if the clock needs to be stepped backwards,
>>figure this out as quickly as possible, before any important services
>>start, accepting that there is some small chance that an additional
>>step in either direction may be required."  It's a straightforward
>>trade-off of the sort engineers make all the time: there's a limit to
>>how much one is willing to pay (in initiailization time) to reduce the
>>likelihood of post-startup nonmonotonicity.  This limit varies
>>depending on the application.
>>
>>    
>>
>
>The pain may be avoided by simply not restarting servers.  This is not 
>possible for some shops but for those that can or must run 24x7 it's the 
>easiest and best solution.  NTPD takes a while to pull into tight 
>synchronization; in some cases as long as ten hours, so there's a big 
>payoff!
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list