[netperf-talk] netperf over low bandwidth network

[Rick Jones]

Frank Schuster wrote:
> Thanks Rick, I add the PAD_TIME and the tcp-tests works well.

I'm a little leery about PAD_TIME - it is a bit of a kludge - a fine kludge for 
single-instance tests but not for aggregates, particularly UDP.  There is some 
handwaving math "fixing-up" the CPU utilization that ass-u-mes the netserver 
system was idle for PAD_TIME.

I'm sort of trying to eschew that in the "omni" tests but it is not complete.

Also, another workaround for TCP_STREAM tests here would be to make the test 
bytecount based rather than time-based.  So something like:

netperf -H <ip> -l -1048576 -- -m 1448

which will send 1 MB of data across the connection and report how long that takes.

happy benchmarking,

rick jones

> 
> Regards
> Frank
> 
> 
>>Frank Schuster wrote:
>>
>>>Hello,
>>>
>>>I tried to use netperf 2.4.5 tcp test over mobile network (gsm/edge) with
>>>small bandwidth.
>>>
>>>I use netperf -H ip_address -l 60 -- -m 1448.
>>>
>>>But I get every time system interrupt.
>>>
>>>I took a look in wireshark and all works really fine, but if the connection
>>>should be close fin/fin-ack/ack. Then there comes hundreds of TCP-RST
>>>messages and then I get only the message in netperf. System interrupt.
>>>
>>>I use ubuntu 9.10 with kernel 2.6.33.
>>>
>>>What I do wrong?
>>>
>>>Regards
>>>
>>>Frank
>>>
>>>PS:
>>>
>>>normal internet browsing and file transfers are possible. Only netperf shows
>>>this behaviour...
>>
>>I'd suggest some system call traces.  Might also check if the pad timer is going 
>>on the netserver side - to avoid blocking on a recv() "forever" the netserver 
>>side may be running a timer with a length of the test time plus PAD_TIME - the 
>>ass-u-me-ption is that netperf would always close the connection before that 
>>expired, but if netperf died, we'd not remain stuck.  If the network is slow 
>>enough, I could see where the linux auto-tuning could allow the socket buffers 
>>to grow to the point that it would take longer than PAD_TIME to drain the 
>>socket, so the doomsday timer expires on netserver, the data connection is 
>>implicitly close()ed and then the arriving stream of segments triggers the RSTs 
>>you see.
>>
>>One alternative would be to set SO_KEEPALIVE and "hope."  Another would be to 
>>set explicit socket buffer sizes via -s and -S to limit how much backlog is created.
>>
>>happy benchmarking,
>>
>>rick jones
>>
> 
> ___________________________________________________________
> NEU: WEB.DE DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit!
> http://produkte.web.de/go/02/