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

Unruh unruh-spam at physics.ubc.ca
Thu Feb 12 21:54:06 UTC 2009

"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. 

>The obvious solution is to keep the machine running.  Some people 
>believe that, for whatever reason, it's not practical for them to do 
>this.  Clearly they need a different tool to set and discipline the 
>clock.  Chrony has been suggested.  AFAIK, chrony runs only on Linux.
>Perhaps those who need a chrony like tool for other operating systems 
>could sponsor ports to other operating systems of interest.

>For most of us, ntpd works very well indeed!

More information about the questions mailing list