[ntp:questions] Re: ntpq times out if NMEA refclock configured?

R Jenkins not at pub.lished
Sun May 14 08:01:27 UTC 2006


"Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message 
news:L7udnQ5X_9grBvvZRVn-vA at comcast.com...
>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 4.2.0a at 1.1190-r 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.





More information about the questions mailing list