[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