Robert Gubler wrote: > Hello, > > I am calling send() at 500 usec intervals with 1514 byte packets (the MTU > size). Occasionally send() will fail with errno set to: "No buffer space > available." > > If I did my math right the theoretical maximum number of packets at 500 usec > intervals is approximately 4. So, at 1 packet every 500 usec I am sending > at a rate approximately equal to 25 MBit/s.
Hmm, maybe the NIC is a bit too slow with handing back the freed buffers (unlikely, though). This problem would be a good candidate for runtime analysis via LTTng - but the patches required for this are currently still only suited for brave early adopters. > > So I guess my first question is, can this buffer space, that the error > refers to be increased? Have I really reached the maximum number of packets > I can transmit? Please have a look at Documentation/README.pools. However, I would suggest trying to find out the reason for this buffer shortage instead of only increasing the pools (not saying the latter is wrong per se). An alternative approach might be the I-pipe kernel function tracer with a long backtrace range so that you can watch out for packet submission vs. buffer releases before that error was reported. This will also require to understand a bit of RTnet internals and its data flow, let us know if you want to go this path and need more help. > > I am using a recently copy of RTnet (SVN revision 1139, I think). Also, I > am using the rt_eepro100 module. > > -Rob > Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
