[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