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

Unruh unruh-spam at physics.ubc.ca
Thu Feb 12 19:17:01 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. 
>> 
>>>> There may well be examples of laptop use cases that require full-blown
>>>> ntpd and where periodic setting using sntp is unacceptable, but I
>>>> think they are rare.
>>>>
>>>> For this reason, I also think that shortening the time it takes ntpd
>>>> to do its initial adjustment is not very relevant to its (presumed)
>>>> design goals.
>>>>
>>>> N
>>> Nero,
>>>
>>> I certainly expect to run NTP on my laptops.  Why should I put up with an
>>> inferior SNTP, loose the ability to retain the drift value between boots,
>>> or have to learn how to configure two different pieces of software?  On
>>> the other hand, providing that the time on the laptops is correct to
>>> within a second, I'm happy.  I'm not looking for much better than 100ms
>>> accuracy.
>>>
>>> I view NTP as a general purpose tool which should be automatically fitted
>>> to /all/ systems, but I am willing to accept that it doesn't work as well
>>> if the system is not permanently switched on.
>> 
>> I absolutely agree. However, this could be enhanced if the initial
>> synchronization would be done faster, and if that was the case I don't
>> think this would result in a limitation for those "big" appliances
>> mentioned by Nero.
>> 
>> Martin

>I think that the design goal was accuracy rather than speed of 
>synchronization.

Chrony demonstrates that greater accuracy than ntp offers together with far
far greater speed is possible. If the design goal was accuracy, it failed.
It was not. It was accuracy using the simplest possible Markovian feedback
design, which means that it has to both be less accurate and far slower
than the ideal.


>If your situation is such that you need to reboot frequently you may 
>have to live with time correct to the nearest second rather than to the 
>nearest millisecond!

Or run chrony if you have linux. 




More information about the questions mailing list