"R Jenkins" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >>R Jenkins wrote: >> >>> Hi, >>> >>> I'm trying to add a GPS refclock to my server. >>> After total failure with a basic Trimble TSIP output GPS plus the parse >>> clock, I'm now using a Garmin GPS25 and the NMEA refclock. >>> >>> I'm getting a very strange effect: >>> >>> If the NMEA refclock is enabled in my ntp.conf, ntpq stops working, it >>> just times out. >>> ntptime still works any gives a something like reasonable display. >>> >>> I have three other servers listed in ntp.conf & simply commenting out >>> the NMEA refclock lines allows ntpq to work again. >>> >>> I've tried commenting out all the restrict lines, this does not change >>> the effect. >>> >>> This is what I'm adding in ntp.conf - I've also tried it with & without >>> the 127.127.22.0 PPS driver & 'enable pps' command. >>> >>> # NMEA Clock using Garmin GPS >>> server 127.127.20.0 prefer >>> fudge 127.127.20.0 refid GPS flag3 1 time1 0.042 >>> >>> ntptime produces this: >>> >>> ntp_gettime() returns code 0 (OK) >>> time c810bfbb.0cb40000 Sat, May 13 2006 21:27:39.049, (.049622), >>> maximum error 192016 us, estimated error 16 us >>> ntp_adjtime() returns code 0 (OK) >>> modes 0x0 (), >>> offset 0.000 us, frequency -495.911 ppm, interval 4 s, >>> maximum error 192016 us, estimated error 16 us, >>> status 0x1 (PLL), >>> time constant 0, precision 1.000 us, tolerance 496 ppm, >>> pps frequency -495.911 ppm, stability 0.000 ppm, jitter 0.000 us, >>> intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. >>> >>> but ntpq does this after about 10 seconds: >>> ntpq -c peers >>> localhost.localdomain: timed out, nothing received >>> ***Request timed out >>> >>> I've previously added the ppskit-lite patch to the kernel, which is >>> 2.6.16.9 on Centos 4.3 x86-64, Athlon 64 CPU. >>> I have udev configured to link /dev/gps0 to /dev/ttyS0 which I believe >>> is what the NMEA refclock expects (& also to /dev/pps0 for the pps >>> clock). >>> The GPS is on ttyS0 with the PPS signal converted to +/- 12V on pin 1. >>> >>> I've tried the standard Centos RPM for NTP & I'm now using one built on >>> the machine from the Redhat source rpm (ntp-4.2.0.a.20040617-4.src.rpm). >>> This seems to be configured as standard to enable all refclocks & it >>> appears to be recognising the kernel PPS capability during the configure >>> stage. >>> >>> Any ideas appreciated! >>> >>> Robert Jenkins. >>> >>> >>> >> >> 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. > > Update: I've just tried building the current dev version (ntp-dev-4.2.1p252-RC.tar.gz) using the ./configure from the redhat source so all the file locations are correct. This behaves exactly the same & logs the same errors. RJ.
_______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
