unruh wrote:
On 2013-05-10, Rick Jones <[email protected]> wrote:
Richard B. Gilbert <[email protected]> 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.

David

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to