[ntp:questions] NTP with GPS and RTC

unruh unruh at invalid.ca
Sat Apr 27 21:25:12 UTC 2013

On 2013-04-27, Joe Gwinn <joegwinn at comcast.net> wrote:
> In article <T8Tet.8216$zH4.3645 at newsfe13.iad>, unruh <unruh at invalid.ca>
> wrote:
>> 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
> Bad link.  Try <http://www.theory.physics.ubc.ca/chrony/chrony.html>.

Yes, that is correct. fingers faster than the brain I guess. Thanks

I advise to subtract 20 from the drift file to give an estimate of how
fast ntpd recovers from a wrong drift, not that that is the perferred
way of operating. Note that Linux for a while would vary in the rate
from bootup to bootup by up to 50PPM, and ntpd-- operating as designed-- 
 would have to try to
recover from that.  Ie, a wrong drift value is NOT a complely out of
this world situation. Similarly, a machine drifting out by 100ms is also
not out of the oridinary for a lengthy shutdown (esp since the rtc is
uncorrected.) If it is out by more, then the stepping of ntpd will come
into play.

More information about the questions mailing list