[netperf-talk] netperf over low bandwidth network

Frank Schuster frank.schuster01 at web.de
Tue Apr 20 01:43:36 PDT 2010


Thanks Rick, I add the PAD_TIME and the tcp-tests works well.

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/


More information about the netperf-talk mailing list