[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