Re: Iperf reporting problems in low-bandwidth environments
This is a very accurate assessment of the limitations of using TCP
and Iperf to test just network throughput. Iperf more accurately measures
"goodput" or the amount of usable data for an application across a
connection. This "goodput" is thus susceptible to all protocol
specific fluctuations in throughput. UDP is a much better mechanism to
test throughput, but may not be as useful for determining actual real
world applications' throughput possibilities. As for your maximum
connections there is no real limit. The limiting factor is your TCP/IP
stack implementation and aggregate throughput. Iperf on the receiving side
only wakes up when traffic arrives so it is dormant for a large amount of
the time.
Kevin
On Tue, 9 Mar 2004, paul shields wrote:
> Related to my previous post on maximum number of clients. I have noticed that in low bandwidth environments, iperf tends to misreport the actual throughput.
>
> Iperf will show wide variations in throughput with peaks higher than the medium can theoretically support. I have a theory about this and just wanted to know what thoughts others had.
>
> Iperf can only measure the rate after the data has been pushed up the TCP/IP stack. Data is only pushed up the stack when it arrives complete and can be properly ordered.
>
> If a sender sends 50 packets in the first second and packet 25 gets lost, iperf will report the throughput based on the 25 packets received at the end of second 1
> In second 2, the sender resends packet 25 and another 49 packets all of which arrive intact. Iperf will report receiving the data from 75 packets in second 2.
>
>
> Is this scenario reasonable and is it potentially one reason why I see unrealistic swings in the reported performance from iperf?
>
> Paul
>