[ntp:questions] NTP with GPS and RTC

Joe Gwinn joegwinn at comcast.net
Sat Apr 27 21:02:43 UTC 2013

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. 
> See
> www.theory.physics.ubc.ca/chrony/chrony.conf

Bad link.  Try <http://www.theory.physics.ubc.ca/chrony/chrony.html>.

Joe Gwinn

> 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