[ntp:questions] What level of timesynch error is typical onWinXP?

David L. Mills mills at udel.edu
Mon Oct 25 18:40:18 UTC 2010


I uttered an egregious, terrible lie: the hold interval is not 600 s; it 
is 300 s, so the maximum time to converge, given a frequency file within 
1 PPM, is five minutes; without a frequency file, within ten minutes to 
0.5 ms and 1 PPM. Again, I caution that if for some reason the  initial 
frequency file is in error something like 500 PPM, there will be a 
considerable additional time to converge.

The model for this scheme is not to fix broken frequency files, but to 
quickly converge after a laptop has been off for a few hours.


David L. Mills wrote:

> Miroslav,
> No, it not expected, unless you are referring to broadcast mode when 
> started with +-100 ms initial offset. That has been corrected as per 
> your bug report.
> For record, a hold timer is started when the first update is received 
> after startup and ends when the residual offset is less than 0.5 ms or 
> after a timeout of 600 s. During the hold interval the PLL loop time 
> constant is set very low and the frequency discipline is disabled. 
> With this arrangement, the offset typical converges within 600 s, even 
> with initial offsets up to +-100 ms, and much less if the initial 
> offset is in the 10-50 ms range. If you see different behavior, either 
> with client/server or broadcast modes, please report.
> Note that, if the initial frequency error is significant, there may 
> still be a surge correction. If the frequency file is not present at 
> startup, the frequency will be measured, typically within +-1 PPM, 
> within 600 s, following with the above scheme will be in effect. Under 
> worst case conditions, there still could be a wobble following startup 
> not exceeding 1 ms. If somebody finds an extraordinarily unlikely y 
> set of circumstances leading to, say 2 ms, I'm not going to lose sleep 
> over that.
> Dave
> The Miroslav Lichvar wrote:
>>On Fri, Oct 22, 2010 at 11:39:47AM +0100, David J Taylor wrote:
>>>Thanks, Dave.  I may be missing something here, but it seems to me
>>>that 4.2.7p58 still takes a number of hours to reach the accuracy
>>>limits where thermal effects dominate.  It's that which matters to
>>>me, rather than something in the first few minutes.  I agree the
>>>graphs would not show such short time-scale initial disturbances.
>>Did the clock frequency change before you started the new version?
>>I played with the latest ntp-dev a bit and there indeed is a
>>improvement on start, mainly when the initial offset is around
>>0.01-0.05s. But the frequency error has to be very small to make a
>>difference, see these plots:
>>Also, I've noticed when ntpd is started without driftfile and the
>>initial offset is over 0.05 second, the overshoot can easily reach 100
>>percent, is this expected?

More information about the questions mailing list