[ntp:questions] ntp & system without a rtc
snews at lordynet.org
Sat May 11 16:58:24 UTC 2013
> 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
> 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
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