[ntp:questions] NTP with GPS and RTC

unruh unruh at invalid.ca
Sat Apr 27 16:37:07 UTC 2013


On 2013-04-27, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> On 27/04/2013 09:13, David Woolley wrote:
> []
>> If the time error is low and bounded the frequency error does not
>> necessarily have a low error bound.  Simply polling fast and using a
>> short loop time constant can give you a low error bound on the time, if
>> the network delays are stable and the source is good.
>
> Thanks, David.  I just checked a power-down reboot of a Windows PC (for 
> replacement of a faulty card) with a PPS reference source, and the 
> jitter was down to its normal value within 20 minutes, and the offset 
> within 15 minutes.  It was much more difficult to judge the time for the 
> frequency to stabilise, because there is so much variation with 
> temperature - perhaps it took 2 to 2.5 hours.  Certainly not then 10 
> hours Bill has often stated.
>
> Another warm PC which had a reboot this morning showed a 12 minute 
> jitter recovery time, 3 minutes for the offset to recover (about 50 
> microseconds typical) and you couldn't see any step in the frequency graph.

Try altering the ntpd drift file (eg representing say 2 days of outage,
not 10 seconds or what used to happen is that Linux's boot recalibration
of the clock would jump by 10s of PPM on each reboot). 

Subract 20 from that value and then start it again. 

See
www.theory.physics.ubc.ca/chrony/chrony.conf
for some test of ntp (towards  the bottom of the page). Note that I was
asking for microsecond accuracy, and ntpd fixes things at a rate of
about a factor of 2 in an hour and a half-- depending on the polling. If
the polling is at 10 ( which I agree it is not on startup), ntp uses
measurements at a rate of about one every 2-3 hours. And on each
measurement there is only a small adjustment in the rate. That is much
longer than 10 hours to recover from a change. 

ntpd, despite Mill's constant protestations that he is totally
uninterested in the speed with which ntpd approaches equilibrium, has
done a few things in the past 5-10 years to speed it up in its startup
operation. And it's 128ms jumps in time (Infinite drift correction) do
quite a bit to hide its slow convergence rate. 



More information about the questions mailing list