[ntp:questions] NTPD can take 10 hours to achieve stability

unruh unruh at wormhole.physics.ubc.ca
Mon Apr 18 17:38:27 UTC 2011


On 2011-04-18, David J Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> "unruh" <unruh at wormhole.physics.ubc.ca> wrote in message 
> news:slrniqnml8.ln1.unruh at wormhole.physics.ubc.ca...
>> On 2011-04-18, David J Taylor <david-taylor at blueyonder.co.uk.invalid> 
>> wrote:
>>> "C BlacK" <rblak at non.net> wrote in message
>>> news:o-adnVWgbZB3NTbQnZ2dnUVZ_oCdnZ2d at supernews.com...
...
>>
>> He was refering to the statement that ntpd can take up to 10 hr to
>> achieve its accuracy. That is the time taken for ntpd to settle down to
>> an accuracy of a few usec if they start off with a few 10s of PPM in
>> rate error.
>
> So, there is an implicit accuracy related to that 10 hour statement, which 
> may not apply to someone else's needs.
>

Agreed. I found that the half life of ntpd is about 1 hr. Ie if your
initial system is off by X and your final desired accuracy is Y, then it takes
 roughly ln2(X/Y) hours to get to your desired accuracy. 


>>> the order of microseconds or better, your PC may need to be in a
>>> temperature controlled environment - how long would it then take to
>>
>> No. With a GPS clock, ntp will run with a few usec error ( about
>> 3-5usec) even in a non-temp corrected environment. But it is clear
>> looking at the errors that it is because ntpd takes so long to settle
>> down that is dominating the errors.
>
> Mine is within about 6 microseconds, in a non-temperature controlled 
> environment (running 24 x 7).  Looking at the plots it is quite clear that 
> temperature variations are the limiting factor in accuracy, and not NTP.

No, it is ntpd. It is because ntpd is so slow to respond to errors that
and it takes so long to correct for those temp changes, that the
accuracy is what it is. (That and ntp's behaviour of throwing away 80%
of the data it collects).

>
>>> stabilise its own temperature?  Compare people using the best frequency
>>> sources, who may need to leave them for days to achieve their best
>>> accuracy.  On the other hand, if all you need is, say, 20ms (the clock
>>> interrupt period on many Windows PCs, so as accurate as a typical 
>>> program
>>> could measure) then NTP might be that accurate just as soon as you've
>>> logged in.
>>
>> Yup. that is certainly true. If all you want is a few ms, then ntp will
>> settle down in a few hours. (See the graph at the bottom of
>> www.theory.physics.ubc.ca/chrony/chrony.html where ntpd started off with
>> with a rate error of 40PPM and took a few hours to settle down to a few
>> ms accuracy.)
>
> Then it could be that you may not not seeing the best which NTP can 
> achieve, if you need to wait "a few hours" rather than a few minutes.  The 
> systems running here, those which are not running 24 x 7, are typically 
> already within few ms after booting up, when you log in.  Not always, but 
> very often.  For example:

IF your file has the correct drift information in it (linux for example
with the tsc clock changes its drift about 40PPM on each bootup) and if
it has not been very long since the machine was switched off, then yes,
it will be accurate very fast. Those are big ifs. The question is how
long does it take ntpd to recover from errors. The figures I gave above
give you a clue. chrony is at least an order of magnitude faster. 

>
>   http://www.satsignal.eu/mrtg/performance_ntp.php
>
> PC Narvik has just been rebooted (09:35 UTC), and is within 0.25ms.  PC 
> Puffin was switch on at about 04:30 UTC after being off overnight and was 
> within about 0.5ms.  These are LAN-synced systems, running Windows, and 
> tuned for that environment.  You would likely not achieve the same either 
> ultimate accuracy or settling time when working from a set of Internet 
> servers, or you have an unfortunate combination of OS, motherboard, 
> application set, or CPU power-saving activation.
>
> Cheers,
> David 
>




More information about the questions mailing list