David Lord wrote:
unruh wrote:
On 2013-05-14, David Woolley <[email protected]> wrote:
Richard B. Gilbert wrote:
NTPD is NOT designed for fast convergence. From start up to get the
minutes correct, NTPD will need about thirty minutes! To get the
best time you are going to get, you will need to wait for about ten
hours!
Convergence to within 128ms should take a lot less than that. With
iburst, I believe it should be less than one minute.
Since ntpd steps ( changes the rate by an infinite slope) if the time is
out by 128 ms, yes, convergence IS faster than that. ( however it has to
make sure that the clock really is out by that much and that takes a few
cycles of clock querrying).
For a ms accuracy your could expect a couple of hours. for 10
microsecond, about 10 hr.
Hi
I posted a reply on May 11, but did not give the ntpq stats
as they'd already been archived away.
After three reboots to replace kernel and userland taking
around 10-15 minutes 'ntpq -p' with polling at 6 minutes gave
the following:
min reach offset jitter
-18 377 -0.001 0.004
-12 377 0.007 0.007
Ouch! I've checked with the actual times logged and there
was no poll logged at 19:30
19:24 -6 377 -0.001 0.006
19:30
19:36 0 0 0.000 0.000
19:42 6 17 -0.036 275.881
12 377 0.126 0.125
18 377 0.173 0.049
24 377 0.047 0.092
30 377 0.007 0.028
36 377 -0.001 0.007
42 377 -0.001 0.004
There was a well established ntp.drift file and my rc.conf starts
ntpd with flags="-g -N -p /var/run/ntpd.pid"
NetBSD/6.1_RC3
ntpd 4.2.6p5-o
PPS from Sure demo board
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions