[ntp:hackers] Running out of Recvbufs

Brian Utterback brian.utterback at sun.com
Fri Dec 2 06:02:55 PST 2005


Danny Mayer wrote:
> Dave,
> 
> I'm revamping some of the receive code in input_handler and I need to
> make some changes. One of the questions is what I do when I run out of
> recvbufs to put the packet in, whether from a network interface or from
> a refclock. I can read it and just throw away the packet or not read it
> and come back later for it. Those are the only choices that I see. One
> of the reasons for wanting to throw away a refclock packet is that there
> are more coming right behind that one and you just build up a backlog. I
>  need your insights on this.

Coming back for it later is definitely the wrong thing to do. Unless
you are on a system that implements the SIOCGSTAMP socket option to
read the receive time stamp of a packet, the only way to timestamp
a packet is by the time that you read it. Any delay in reading the
packet adds to the jitter of the calculated time offset at the
client. That is why ntpd reads all the packets as fast as it
can and only processes them when there is nothing to left to
read. The actual time that it takes to process a packet is irrelevant
to the timestamp calculations. Only the time before the receive
timestamp and after the transmit timestamp is important.

So reading it and throwing it away is better than leaving it on the
socket unread, unless we are using SIOCGSTAMP.

One problem with this is that it leaves to potential service
starvation. If packets arrive at the same rate or faster than
it takes to read them, then already received packets might never
be processed. Of course, once the UDP receive buffer is full,
the packets will be dropped anyway.

So, one possible solution to that would be that when you run
out of recvbufs, leave the packets on the socket unread,
process some percentage of the buffered packets, and then
flush all the queued packets and drop them, up to some maximum
capped number of packets. You need the cap so that if the
packets arrive faster than you can read them, you are not once
again starved forever. But you need to make the cap large enough
to be sure that you have read all the packets that might have
been queued while you were processing the already buffered packets.

Perhaps we should be able to tinker the number of recvbufs?


-- 
blu

"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list