David Lord wrote:
David Lord wrote:
that I can't get parallel (or serial) pps to work with just
ATOM driver flag3 0 | 1 (kernel discipline disable | enable)
and no other refclock, ie I'd like to just use another ntp
server as preferred with pps to condition the clock.
Don't know what I did wrong previously but just removed
127.127.20.0 lines from ntp.conf, set me6000g as prefer,
restarted ntpd and had following:
oPPS(0) .PPSb. 377 -0.002 0.004 pps from GPS
*k6x400 377 0.246
+me6000g .PPSa. 377 0.106 pps from MSF
-p4x2400c 377 0.533
The above with parallel pps0 at ppbus and /dev/pps0
created using mknod same as tried earlier.
Also tried with p4x2400c as prefer and that's ok.
Replaced /dev/pps0 with /dev/pps0 -> /dev/tty00
disconnected parallel port, reconnected serial (DCD and RxD),
restarted ntpd and that's working ok.
Can't think what I've done different. Then again MSF
wouldn't sync end of last week after I'd made a change
to ntp.conf and then I noticed LED on receiver wasn't
flashing.
Short term memory loss I think.
I'd no sooner posted that when oPPS(0) flipped to -PPS(0)
and continued flipping with offset increasing from 4u
to 145u. I then restarted with kernel pps selected
(flag3 1). That was no better, and same when I went back
to parallel port still with kernel mode pps. I even
mentioned this behaviour in a much earlier message.
Now back to parallel port with PPSAPI (no flag3) and so
far this does seem to be converging with PPS(0)
remaining selected as pps.peer for 25 minutes so far
(no doubt until I hit the send button). Offset has
converged from > 250us to 12us with jitter now at 4us.
cheers
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
