[ntp:questions] ntp & system without a rtc

David Lord snews at lordynet.org
Sat May 11 16:58:24 UTC 2013

unruh wrote:
> On 2013-05-10, Rick Jones <rick.jones2 at hp.com> wrote:
>> Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>> I think you may be out of luck on this one.  If you can run NTPD 24x7
>>> you can have the correct time 24x7.  If you can't do this, NTPD is a 
>>> poor choice.  The problem is that NTPD needs something like ten hours to 
>>> select a time source and match the time!
>> NTPD is no speed daemon, and perhaps it is a subjective thing, or a
>> mis-interpreation on my part, but I notice NTPD declaring sync rather
>> sooner than 10 hours.  Rather sooner than one hour even (looking at
>> ntpq -p output).  Now, it may indeed take it a long time to get the
>> offset (term?) down to some acceptable level, but that depends on
>> one's definition of acceptable and the initial distance no?
> Yes. The 10 hours is for achieving the ultimate accuracy of a few
> microseconds offset. It has a halving time of a bit under an hour (lets
> say 45 min) . Ie,
> after 45 min, the size of the offsets is about 1/2 of what it
> was before. Because of stepping it has an error of about 100ms to start
> out. 
> If you are happy with few millisecond precision, it will only take an hour
> or two.
> So if you start it out with the -g it will figure out is is way out
> after a few seconds, and step. But the rate in general will still be
> out, so it will rapidly drift away and ntpd will slowly bring the drift
> into order. 
> Thus to get from hours out to hundreds of milliseconds out should occur
> very quickly. 

My pc with GPS was last restarted April 28 and involved three
reboots for a NetBSD update from 6.1_RC2 to 6.1_RC3. The pc
is in a south facing unheated bedroom.

Offset logs from "ntpq -crv -p" polling period 6 min:
20130427:   -0.000000 - +0.000065 s
20130428:   -0.000000 - +0.000897 s  = +897 us
20130429:   -0.000000 - +0.000043 s

loop_summary has:
                     rng(us)      rms               freq
20130427:      16 +/-    50      7.7   -36.07 +/- 0.492
20130428:  -40410 +/- 64152   2929.6   -36.32 +/- 0.202
20130429:       6 +/-    36      4.9   -36.29 +/- 0.265

So would suggest if the requirements are within a few ms
and with an existing established driftfile in place that
ntpd might be ok.

If the system is not powered continuously I believe chrony
might be a better choice, although when I used chrony it was
for on-demand-dialup to "demon" and pcs were powered up 24/7.


More information about the questions mailing list