[netperf-talk] Patch for demo mode

[Rick Jones]

On 07/30/2012 11:58 AM, Cook, Jonathan wrote:
> 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.

I agree that reporting the sending side of a UDP_STREAM test is 
sub-optimal.  Been that way since demo mode was added to netperf :)

So, either using the absolute and elapsed time as seen by netserver, or 
have netserver send the interim results to a file would seem to be the 
way to go.  Sending the results to a file will still have the "accessing 
the remote" issues (unless sent at the end of the test, but then there 
is still the issue of interaction with other tests) but it won't be 
trying to have traffic on the control and data connections at the same time.

rick

>
> 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
>