Iperf reporting problems in low-bandwidth environments

To: <iperf-users --at-- dast.nlanr.net>
Subject: Iperf reporting problems in low-bandwidth environments
From: "paul shields" <pshields --at-- NAVINI.com>
Date: Tue, 9 Mar 2004 17:02:03 -0600
Content-class: urn:content-classes:message
Content-transfer-encoding: 8bit
Content-type: text/plain;charset="iso-8859-1"
Reply-to: iperf-users --at-- dast.nlanr.net
Sender: owner-iperf-users --at-- dast.nlanr.net
Thread-index: AcQGKokT0+JME71ORRW06ClD79to4w==
Thread-topic: Iperf reporting problems in low-bandwidth environments

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

Follow-Ups:
- Re: Iperf reporting problems in low-bandwidth environments
  - From: Kevin Gibbs

Prev by Date: Re: [Fwd: Iperf bug?]
Next by Date: Iperf logging oddity on Linux with iperf 1.7.0
Previous by thread: Maximum number of clients per server
Next by thread: Re: Iperf reporting problems in low-bandwidth environments

Other Mailing lists | Author Index | Date Index | Subject Index | Thread Index