Subject: [ntp:questions] Re: ACTS - too many recvbufs allocated (40)

Greg Dowd GDowd at symmetricom.com
Tue Feb 8 17:58:54 UTC 2005


See bugzilla report 367.  Dave and I talked about this last year.  There
was confusion regarding the C0/C1 versus the &C0/&C1.  It needs to be
&C0, at least for Linux.  I still don't have my Solaris box running ntp
dev.  The comment was updated but the code was not.   Last time I
checked was the middle of Jan but I'm still waiting.  Having made the
change, I've run the driver with good results (~2.5ms rms) but I have an
issue that maxpoll clamps at 2^^10(1024).  Ergo, 900 phone calls over my
1 week test.  Luckily, it's not my phone bill.  Any guesses on that?


server 127.127.18.3 prefer  # I needed the prefer to keep it from
switching to my local s1 ntp server?
phone ATDT13034944774
server 192.168.19.7  # local subnet GPS based ntp server
# Disallow all ntpdc commands from everybody...
restrict default nomodify
# ...but allow ntpdc from loopback
restrict 127.0.0.1
trustedkey 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16 99
keys /usr/local/etc/ntp.keys
statsdir /tmp/
statistics peerstats rawstats loopstats




Greg Dowd
gdowd at symmetricom dot com (antispam format)
Technologist, TT&M Div.
Symmetricom, Inc. 
www.symmetricom.com


Message: 4
Date: 7 Feb 2005 22:17:47 GMT
From: Ronan Flood <ronan at noc.ulcc.ac.uk>
Subject: [ntp:questions] Re: ACTS - too many recvbufs allocated (40)
	(Correct the Version of ntp-dev)
To: questions at lists.ntp.isc.org
Message-ID: <cu8peb$ou9$1 at canard.ulcc.ac.uk>

cipo <cseplo_l at netlock.net> wrote:

> Without C1->C0 change in the modem initialization string (for the 
> Europian time services of course) the serial port return 0 bytes.
> In ntp_io.c/void input_handler(l_fp *cts)
> select(maxactivefd+1,...) triggered,
> ...
> rb=get_free_recv_buffer(); buffer allocated
> ...
> rb->recv_length=read(fd,...); read 0 bytes !!!
> if(rb->recv_length == -1) {
>     handled as error, buffer released.
> }
> 
> But in the case of rb->recv_length=0, buffer remains allocated, 
> select(...) triggered again, (in ntpd.c/service_main too)  reading 0 
> bytes again, 40 times, then the message in the subject appears. If the

> rb->recv_length=0 handled as above (buffer released, goto
select_again) 

"continue" is probably a better move than "goto select_again",
but that's a minor point.

> than there is an infinite loop with 100% proc consumed. Another
approach 
> is required.
> If C0 patch applied, this not happens.
> I don't now the correct solution yet.

Sounds like a hangup.  Do you have anything connected to the DSR line
of the serial port?  If so, you could try disconnecting that; which
should leave CLOCAL set on the port so that hangups are ignored -- see
refclock_open().

-- 
                      Ronan Flood <R.Flood at noc.ulcc.ac.uk>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't
like)




More information about the questions mailing list