[netperf-talk] Patch for demo mode

[Cook, Jonathan]

Rick,
You bring up some valid points.  I think, though, that the current implementation gives misleading information when performing a UDP send test and I believe this is an improvement.  It is not always possible to login to a remote server (especially when conducting wireless tests in the field as I am doing) so I need some more accurate interim results from the netperf side.  It makes sense to enhance the patch by using the elapsed time from netserver instead of the timestamps from netperf.  I threw that information in the message from netserver, but didn't use it because it was easier not to.  When I have some time I can look into doing that.

Regards,
Jon Cook

-----Original Message-----
From: Rick Jones [mailto:rick.jones2 at hp.com] 
Sent: Monday, July 30, 2012 11:07 AM
To: Cook, Jonathan
Cc: netperf-talk at netperf.org
Subject: Re: [netperf-talk] Patch for demo mode

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