[netperf-talk] netperf2.4.4 on linux, socket size issue ?

[Andrew Gallatin]

Rick Jones writes:
 > Andrew Gallatin wrote:
 > > Rick Jones writes:
 > >  > beginning.  So, while in both cases above, netperf is reporting the same 
 > >  > socket buffer sizes, in one case, Linux has gone behind netperf's back 
 > >  > and ended-up using even larger socket buffers.  This is another in a 
 > >  > series of things where Linux wanted to be different from everyone else 
 > >  > and in so doing changed/violated some basic assumptions about stack 
 > >  > behavour implicit in netperf. (and perhaps other benchmarks too)
 > > 
 > > 
 > > I'm not generally a Linux fan, but I'd say the benefits of autotuning
 > > far outweigh the drawbacks.  If the application cares, it can set the
 > > buffer sizes itself.  FWIW, the autotuning has spread to FreeBSD, and
 > > even Solaris is talking about doing it.
 > 
 > I am probably just being a curmudgeon :)  What irks me most though is 
 > that by default it seems the autotuning is allowed to take a socket 
 > buffer much farther than an application is allowed to directly.

I'm a curmudgeon too!  At least in FreeBSD the autotuning is *not*
allowed to make the socketbuffer bigger than an app can do by
itself.

 > Also, at present, if one runs the omni tests over a 1GbE link, you will 
 > notice that the autotuning takes the socket buffer size to the max, 

These omni tests are only present in the xml'ized netperf svn tip, not in
2.2, right?  Would you accept a patch to have 2.2 spit out the ending
size with a -v 2 in 2.2?  I never even considered that you'd be able
to obtain that value via getsockopt(...SO_SNDBUF..).  Cool..

Drew