[ntp:questions] NTP with GPS and RTC
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.
Bad link. Try <http://www.theory.physics.ubc.ca/chrony/chrony.html>.
> 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