David Lord wrote:
16 July
09:56:27 ntpd exiting
09:56:39 clock PPS(2) event clk_noreply
10:01:01 synch to GPS_NMEA(2), stratum 0
10:01:01 kernel time sync status change 0x2101
10:02:02 kernel time sync status change 0x2107
10:02:17 synchronized to PPS(2), stratum 0
and "ntpq -p" gives PPS(2) offset 0.000ms and
other servers on lan < 1.4ms.
OOPS
I had the parallel pps connected to where the watch xtal
osc had been disconnected so above is with normal serial
dcd pps from the gps.
I've now connected pps output from gps to the parallel
port with one of local servers as prefer.
oPPS(0) .PPSb. 1 l .... 377 0.000 -0.010 0.011
.....
+server .MSFa. 1 u .... 377 0.654 0.505 0.588
Using the gps serial output gives a known problem
where offset is too far out from the pps so requires
selection of a fudge time for pps to kick in. If
lucky pps is eventually selected.
oPPS(0) .PPSb. 0 l .... 377 0.000 27.190 10.338
+GPS_NMEA(2) .GPSb. 0 l .... 377 0.000 42.004 10.348
.....
+server .MSFa. 1 u .... 377 0.843 71.197 19.625
Another 20 minutes and pps offset has only fallen
to -3.3ms so startup and convergence can be a
lot slower with larger initial offset than using
a server on lan but stratum 0 is obtained with
offset of a few us.
Before someone chimes in, the fix does not seem
to be available in the ntpd source (NetBSD-5
STABLE has 4.2.4p6-o)
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
