[netperf-talk] Patch for demo mode

[Rick Jones]

On 07/27/2012 03:33 PM, Cook, Jonathan wrote:
> I have encountered a problem with netperf when using demo mode to
> display periodic performance reports.  The –D option works well in most
> cases, but when sending UDP data from netperf to netserver the reports
> show how much data is being sent from netperf, not how much data is
> actually making it through the network to netserver.  There can be a
> significant difference between the two numbers.  I have attached a patch
> which changes the behavior so that on an OMNI  UDP send test information
> is sent periodically from netserver to netperf indicating the actual
> throughput.  Netperf then displays the interval results based on the
> received data instead of the sent data.
>
> Please take a look at the patch and let me know what you think.

As part of my "day job" one of the things I have worked-on was something 
to stuff sFlow counter samples into an rrdtool database.  One of the 
things I noticed was if my application fell behind the socket for any 
length of time, the timestamps on my rrd entries would be messed-up. 
Root cause was I was using the timestamp of the time I did the recv() to 
pass to the rrd, but if the application fell behind for a bit, as it 
caught-up all the timestamps would be "compressed" for that reason, I 
started using SO_TIMESTAMP (which I could, because I knew it was 
supported on the only platform where I was going to run this binary).

In that vein I am concerned that the timestamps of the interim results 
are still being generated by netperf rather than netserver.  If netperf 
falls behind in draining the control socket, the timestamps on the 
interim results will compress as it catches-up.

Also, while 99 times out of 10 the world is duplex, there are still 
frequent cases when there can be tests "running in the other direction" 
which may mean that the control connection itself could back-up - lose a 
TCP segment, have to retransmit, bunch-up the interim results contained 
therein and even with netperf keeping ahead of things, a slug of interim 
results will arrive.  So, SO_TIMESTAMP won't really work for that even. 
(My "day job" situation was using UDP where the semantics of 
SO_TIMESTAMP fit better)

And... I'm concerned about having control traffic during the data 
portion of the test.  Again for a single instance of netperf that 
probably isn't a big deal (though in some cases in the past, a 
UDP_STREAM test has managed to get the path so messed-up it toasted its 
own control connection...) but for multiple instances of netperf it 
could be an issue.  These interim results are "time sensitive" and the 
control connection has never before been used for anything time sensitive.

While there is still the matter of being able to login to the remote, I 
think this is a situation where using a "UDP_MAERTS" test and leaving 
the interim results generation entirely in the hands of netperf would be 
better.

happy benchmarking,

rick jones