[ntp:hackers] Running out of Recvbufs

David L. Mills mills at udel.edu
Fri Dec 2 22:14:32 PST 2005


Danny,

Sorry; my grad students concluded this was the wrong way to write an I/O 
system. They concluded the right way was as separate modules for each 
operating system and not the threaded weeds we have today. I'm not 
saying they are right or wrong, just that an attempt to fix weeds and 
harmonize the result is beyond the capability of grad students. I'm not 
happy with that result.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> Danny & Corps,
>>
>> The I/O code came from the original NTPv0 implementation circa 1988, but
>> has grown large weeds over the years. It got so bad my grad students
>> refused to maintain it. I don't know who decided that 40 buffers were
>> appropriate, but if the queue gets that long, something is seriously
>> broken. There have been times when something was broken and a buffer
>> leak mopped up all the mbufs in the machine. I conclude that it doesn't
>> matter which end of the queue to trim, just to assume a full queue means
>> fix what broke.
>>
>> Refclocks are a special case only that all known drivers write data from
>> their own internal buffers. Data are read using the I/O system so far as
>> I know using the same buffer pool. In general, network packets and input
>> serial data can be dropped without caring much about it. The protocol
>> and implementation are inherently resistant to occasional data loss.
>>
>> Having said that, it's better to discard data rather than keep it around.
>>
>> Dave
>>
>
> Dave,
>
> I cannot understand why your grad students would find the code that
> weedy. The recvbuff code is just linked list kind of stuff. I dumped all
> of it in favor of a standard ISC linked list as it was kind of weird the
> way it worked. I'm not worried about that part.
>
> Originally, I had lifted the buffer limit to be essentially unlimited as
> long as there was enough memory, but as we found out on bridgeport it
> seemed to take over and kill the system which is why I'm putting it back
> to 40. (I'll take recommendations about what a good max is later).
>
> My concern is what to do when the buffers hit the limit. The code will
> now dump all unserviced packets once the limit is hit. It will then go
> out and service the filled buffers and then come back for more.
>
> Danny




More information about the hackers mailing list