"David Lord" <[email protected]> wrote in message
news:[email protected]...
[]
Now NMEA(0) 92u/6u and PPS(0) 75u/2u, 60 minutes after ntpd restarted.
Config:
pps to lpt0
pps to serial dcd
lpt0 at ppbus
pps0 at ppbus
crw-r--r-- 1 root wheel 164, 0 Feb 7 01:47 pps0
server 127.127.20.0 mode 1 prefer minpoll 6 maxpoll 8
server 127.127.22.0 minpoll 4 maxpoll 6
7 Feb 01:46:18 ntpd exiting on signal 15
7 Feb 01:47:38 clock PPS(0) event 'clk_noreply' (0x01)
7 Feb 01:51:58 synchronized to 192.168.59.60, stratum 2
7 Feb 01:51:58 kernel time sync status change
0x2001<PLL,NANO,MODE=0x0=PLL,CLK=0x0=A>
7 Feb 01:51:59 synchronized to GPS_NMEA(0), stratum 0
7 Feb 01:53:09 synchronized to PPS(0), stratum 0
remote refid st t when poll reach delay offset jitter
======================================================================
+GPS_NMEA(0) .GPS. 0 l 19 64 377 0.000 -1.680 253.141
oPPS(0) .PPS. 0 l 10 16 377 0.000 -1.652 0.150
-k6x400 xxx.xxx.xxx.xxx 2 u 26 64 377 0.740 0.822 0.778
+me6000g .PPS. 1 u 21 64 377 1.767 -0.439 0.309
-p4x2400c xxx.xxx.xxx.xxx 2 u 22 64 377 1.893 0.611 0.520
David,
Thanks for the details. My (rather limited) understanding was that the
atom driver was simply a filter on an existing PPS signal, and therefore
you would need a driver which knew about the LPT port and could detect and
use its PPS signal. Which driver does that I don't know, as I've never
used one.
Now NMEA(0) 92u/6u and PPS(0) 75u/2u, 60 minutes after ntpd restarted.
Are these jitter/offset figures? Do I gather that the 253 milliseconds
NMEA jitter was at the start, and it's now 6 microseconds? Why so bad at
the start, or was that simply the first reading? But it can't be the
first reading as it shows Atom sync, which was 7 minutes after the start.
The "billboard" NMEA jitter figure puzzles me!
Cheers,
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
