[netperf-dev] Any stacks out there willing to tell me about queued but unsent data?

[Rick Jones]

I'm wrestling with something in netperf and could use some help.  I
try to have my cake, eat my cake and perhaps even have someone else
pay for the cake when it comes to measuring maximum packets per second
with single-byte, burst-mode netperf TCP_RR tests.  I ass-u-me that if
I set TCP_NODELAY, and am careful to walk-up the number of outstanding
transactions at one time on the connection (to deal with an initial
congestion window) then I can take my transactions per second and
multiply it by two to get packets per second (when my request and
response sizes are < the MSS).

Now, if there are any TCP retransmissions, that assumption rather goes
out the window.  If I am doing "by-hand" performance testing with a
single system I can wrap my netperf commands with netstat easily
enough and see if the assumptions hold.  I can even wrap the netperf
command with some link-level statistics gathering and further check
things.

However, when I am running large-scale, automated tests that starts to
become impractical.  Particularly if I'm talking about say hundreds of
simultaneous netperf instances.  In that case I rather need each
netperf to have some way to ascertain that bundling is taking or may
have taken place.

Under Linux I can see if there have been any retransmissions on the
connection via a getsockopt(TCP_INFO).  I could then ass-u-me that if
I checked that periodically (infrequently enough to keep the overhead
low), and noticed the total retransmission counter increasing that
I've had retransmissions and restart my own "slow-start" but what I
think would be more helpful/immediate would be some way to know if
there is data queued to the connection but not yet sent.  Are there
any stacks out there which can do that with some sort of getsockopt()
or ioctl()?

I'm sure there is nothing "universal" out there, particularly since
I'm cheating about a fundamental aspect of TCP here - that it is but a
byte-stream.  But if there is a way to get closer I'd love to hear
about it.

happy benchmarking,

rick jones