[netperf-talk] NetPerf issue with intervals approaching line-rate.

[Rick Jones]

On 07/13/2011 08:34 AM, Moosa Baransi wrote:
> Hi Raj,
>
> My name is Moosa and I am working with NetPerf 2.4.5. I encountered a
> problem which I can't find a solution for it in the different forums.

Then we should include one or more forums to improve life for the next 
guy.  So, I will cc netperf-talk and include a more informative subject 
header.

> _The problem description_:
>
>     I'm working on a board which has a max UDP throughput of about 10
>     Mbps. I verified that with NetPerf using the command:
>
>
>     *netperf -H 192.168.1.106 -D 2 -l 20 -t UDP_STREAM -fm -- -m1472
>     -s64k -S64k &*
>
>
>     I would like to use the burst option to measure how it impacts the
>     CPU utilization. I am running the following command:
>
>
>     *netperf -H 192.168.1.106 -D 2 -l 20 -t UDP_STREAM -b5 -w0 -fm --
>     -m1472 -s64k -S64k &*
>
>
>     The issue that if I change the burst to anything close to 10Mbps
>     (*-b9* or above), I get the following error:
>
>
>     *netperf: receive_response: no response received. errno 4 counter -1.*
>
>
>     The host and the server are running NetPerf 2.4.5.
>
> I do not care if I have packet loss or retries, I just want the whole
> business to go on and not to hang in the middle.
>
> I will appreciate of you can help me with this.

I'm guessing that when you get the error, it happens well before the 
requested test length has passed?

Unless one uses --enable-spin to cause netperf to sit and spin for the 
interval, which I suspect you do not wish to do, the interval is 
implemented with the interval timer.  Every interval time units a signal 
is generated.  If you look at the code for INTERVALS_WAIT you will see 
it makes a sigsuspend() call.  The idea is that netperf is in 
sigsuspend() before the signal fires.

Now, on some platforms, netperf knows how to check what system call was 
interrupted by the signal, and when it is in the middle of an interval 
it will ask that the system call be restarted if it isn't sigsuspend().

However, on other platforms netperf does not know how to do that. 
(enhancement patches would be most welcome :) So, if it takes longer 
than the interval to get through the burst, there is a very real chance 
the signal will fire during the send()/sendto() call, which netperf will 
mis-interpret as the end of test indication.  On those platforms, it is 
necessary to ensure that the burst interval is longer than the length of 
time it takes to send the burst.

happy benchmarking,

rick jones