After rereading a little more carefully, I notice that your frequency
correct of -495.9 PPM is on the ragged edge of the 500 PPM limit. It is
unusual for a clock to have a freqency error this large; most are below 50
PPM in absolute value.
Does your system have a kernel parameter called "HZ"? Is it set to a
value greater than 100? I believe I have seen references to values of
both 250 and 1000; neither value works well with NTPD. The system seems
to lose clock interrupts when HZ is greater than 100. YMMV but if you are
not using 100, give it a try.
Hi,
thanks for the replies.
The -495.9 ppm seems to be a symptom of the refclock problem. Without the
NMEA refclock it was -60 after a few minutes, long before it had settled
properly.
I think it does have a fast Hz setting (I've seen it somewhere but I can't
remember where or what it was set to..) However, it's a 3.2GHz processor so
I don't think it should struggle too much.
I have the PPS pulse set to 200mS.
The PC does not normally have a display, I use telnet (well, SSH) from my
desk.
Running minicom at 4800 Baud with NTPD stopped shows the GPS serial data is
present:
$GPRMC,073153,A,5319.0516,N,00106.9355,W,000.0,000.0,140506,004.0,W*76
$GPRMC,073154,A,5319.0516,N,00106.9355,W,000.0,000.0,140506,004.0,W*71
$GPRMC,073155,A,5319.0516,N,00106.9355,W,000.0,000.0,140506,004.0,W*70
...
I'm not sure how to remotely monitor the DCD line.
Simply having the 'server 127.127.20.0 prefer' line in causes the ntpq hang.
I've just got around to checking the log immediately after starting ntpd:
May 14 08:19:51 gate2 ntpd[28723]: ntpd [EMAIL PROTECTED] Sat May 13 10:39:48
BST 2006 (1)
May 14 08:19:51 gate2 ntpd[28723]: precision = 1.000 usec
May 14 08:19:51 gate2 ntpd[28723]: Listening on interface wildcard,
0.0.0.0#123
May 14 08:19:51 gate2 ntpd[28723]: Listening on interface wildcard, ::#123
May 14 08:19:51 gate2 ntpd[28723]: Listening on interface lo, 127.0.0.1#123
May 14 08:19:51 gate2 ntpd[28723]: Listening on interface eth0,
192.168.0.43#123
<Other interfaces trimmed>
May 14 08:19:51 gate2 ntpd[28723]: kernel time sync status 0040
May 14 08:19:51 gate2 ntpd[28723]: refclock_nmea: time_pps_kcbind failed:
Invalid argument
May 14 08:19:52 gate2 ntpd[28723]: too many recvbufs allocated (40)
It looks like there is some problem with the kernel PPS interface, but I
have no idea what...
I used this patch:
PPSkit-light-alpha-3328m-2.6.15.1.diff
on a clean download of kernel 2.6.16.9 - there were a couple of rejects, but
they seemed to be pretty obvious & went in easily by hand..
I'm happy to try another (recent) 2.6 kernel if there is one with a known
working patch?
Another test: Leaving the 'flag 3 1' out stops the refclock error line in
the log.
The 'too many recvbufs allocated (40)' line seems to be triggered by the
NMEA refclock regardless of any other settings; it does not appear when the
NMEA clock is commented out in ntp.conf
Robert Jenkins.
