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

Richard B. Gilbert rgilbert88 at comcast.net
Sun May 14 14:23:42 UTC 2006

R Jenkins wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message 
> news:L7udnQ5X_9grBvvZRVn-vA at comcast.com...
>>R Jenkins wrote:
>>>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.
<big snip>
>>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 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, 
> 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,
> May 14 08:19:51 gate2 ntpd[28723]: Listening on interface eth0, 
> <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-
> on a clean download of kernel - 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.

If the HZ setting is causing the problem, it has little to do with 
processor speed!!   The problem seems to be that various device drivers 
mask or disable interrupts for a period covering two or more clock 
interrupts causing one or more to be lost with each occurrence.

The messages about "too many recvbufs allocated (40)" were associated 
with a bug in ntpd that I believe was fixed more than a year ago.  You 
might want to try the latest version of ntpd.  You can download it from

More information about the questions mailing list