[netperf-talk] ENOBUFS on linux?

[Andrew Gallatin]

Please see attached patch, which only sets the option for the send
side of UDP_STREAM, and even there, only on linux.   You mentioned
that HPUX does this as well.  It might be interesting to see if
this "fixes" HPUX also (you'll need to adjust the #ifdefs).

Rick Jones wrote:
> If you can show the effect on achieved performance is epsilon for the 
> cases when the drops don't occur I'm OK with that (preferably with 
> something other than a 100 Mbit/s link, or at least with high confidence 

I'm not used to the conf. interval stuff.  Is this what you want to see?
In the tests below "netperf.orig" is a build of the 2.2 svn before
applying my patch, and "netperf" is after the patch.

% build/src/netperf.orig  -H10.1.171.14 -tUDP_STREAM -T4,4 -I 99 -C -c 
-- -m 1472 -S 32K -s 32K
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
10.1.171.14 (10.1.171.14) port 0 AF_INET : +/-49.500% @ 99% conf.  : cpu 
bind
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

  65536    1472   10.00     4418311      0     5202.6     0.72     0.091
  65536           10.00     4411851            5195.0     8.01     1.010


% build/src/netperf -H10.1.171.14 -tUDP_STREAM -T4,4 -I 99 -C -c -- -m 
1472 -S 32K -s 32K
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
10.1.171.14 (10.1.171.14) port 0 AF_INET : +/-49.500% @ 99% conf.  : cpu 
bind
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

  65536    1472   10.00     4418839      0     5203.2     0.72     0.091
  65536           10.00     4412634            5195.9     8.11     1.023


And for the case with drops:

% build/src/netperf.orig  -H10.1.171.14 -tUDP_STREAM -T4,4 -I 99 -C -c 
-- -m 1472 -S 2M -s 2M
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
10.1.171.14 (10.1.171.14) port 0 AF_INET : +/-49.500% @ 99% conf.  : cpu 
bind
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304    1472   10.00     9085361      0    10698.2     15.82    1.085
4194304           10.00     8117546            9558.6     11.21    0.768


% build/src/netperf -H10.1.171.14 -tUDP_STREAM -T4,4 -I 99 -C -c -- -m 
1472 -S 2M -s 2M
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
10.1.171.14 (10.1.171.14) port 0 AF_INET : +/-49.500% @ 99% conf.  : cpu 
bind
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304    1472   10.00     8115896 1131544     9556.5     15.85    1.087
4194304           10.00     8115896            9556.5     11.19    0.767


> level service demands).  Bonus points for making sure it works with the 
> omni tests (although IIRC those are already using the nettest_bsd.c 
> create_data_socket() stuff anyway)

The way I did it probably won't work with them.  I couldn't figure out
how to run them, so I didn't attempt to fix them as well.

> I would also like to know that it doesn't get in the way of a TCP_CC or 
> TCP_CRR test, as that will be creating lots of data sockets and so 
> "extra" setsockopt() calls are generally to be avoided.

It can't, since it is called only for the send side of UDP_STREAM.

Drew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enobufs.diff
Type: text/x-diff
Size: 1434 bytes
Desc: not available
URL: <http://www.netperf.org/pipermail/netperf-talk/attachments/20100520/b007dae4/attachment.diff>