[ntp:questions] NTP with GPS and RTC
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>
>> 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.
> 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
More information about the questions