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

Richard B. Gilbert rgilbert88 at comcast.net
Fri Feb 13 00:26:40 UTC 2009


Unruh wrote:
> "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. 
> 
> 

Too many cooks. . . .




More information about the questions mailing list