[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)

Unruh unruh-spam at physics.ubc.ca
Thu Feb 12 23:51:20 UTC 2009

"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>Unruh wrote:
>> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>>> Martin Burnicki wrote:
>>>> David J Taylor wrote:
>>>>> Nero Imhard wrote:
>>>>>> Martin Burnicki wrote:
>>>>>>> Why shouldn't ntpd be run e.g. on a laptop?
>>>>>> [...]
>>>>>>> And surely this results in the question which has been discussed here
>>>>>>>  several times: why does it takes so long for ntpd to adjust an
>>>>>>> initial tiny offset of a few milliseconds?
>>>>>> In my understanding, ntpd was designed as a tool to discipline clocks
>>>>>> of systems that need (or need to provide) very accurate time, and not
>>>>>> as a general-purpose clock-setting tool.
>>>> The original (x)ntpd has been designed long time ago, when there was much
>>>> less computing power than today. Under those circumstances it may make
>>>> sense to think about running ntpd on a system, or not.
>>>> Today's standard machines are so powerful that ntpd is a tiny application
>>>> (in the sense of resource usage, of course not in the sense of the work it
>>>> does). It comes by default with many Unix-like distributions which are not
>>>> only installed on servers, or if required for academic studies. 
>>>> The number of downloads of the Windows installer clearly shows that ntpd
>>>> also becomes more and more widespread even in the Windows world, and
>>>> presumably not only on servers.
>>>>>> The requirements that would mandate the use of full-blown ntpd are
>>>>>> mainly found on systems that stay up and connected for long stretches
>>>>>> of time (time servers, measurement and monitoring systems, loghosts,
>>>>>> file servers, etc.).
>>>> Even systems which are running continuously for a long time may need to be
>>>> rebooted sometimes, or ntpd restarted, and I'm sure the operators would
>>>> appreciate if the time offset will decrease quicklier than it currently
>>>> does, which is clearly possible. 
>>> If you start with the -g option, the time is set initially and the error 
>>>  should be very small.  Setting the frequency correction to the correct 
>>> value is what can take a great deal of time.  Restarting with -g and a 
>>> valid drift file should allow ntpd to converge fairly quickly.
>> If only Linux had not screwed up the calibration of the system clock, so
>> that the drift rate varies by up to 50PPM on each reboot. Means it takes
>> about 10 hours for the system to recalibrate and settle down. 
>>> What seems to take a great deal of time is a cold start.
>> Or a warm start with a "bad" drift file. 

>I'd be very cautious about using a drift file that was much more than 
>one hour old.  If the environment (temperature) has remained constant 
>you are probably okay but the greater the length of time you are down 
>the greater the uncertainty of the time you will start up with.

On Linux these days, even a drift file that is 10 sec old is useless, since
the system clock drift rate changes by up to 50PPM over a reboot. 

More information about the questions mailing list