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