Package: iperf Version: 2.0.5-3 Severity: important Tags: upstream Dear Maintainer,
Troubleshooting the cause of unexpectedly poor benchmarking at high packet-per-
second rates of UDP it was found that the iperf package included in squeeze
(2.0.4) performed significantly better than that which is included in wheezy
(2.0.5).
This behaviour was verified across several machines and can be replicated using
the loopback adapter, eliminating network cards and drivers.
While iperf 2.0.4 in squeeze is capable of generating large numbers of packets
per second in UDP mode (we have observed over half a million), 2.0.5 in wheezy
consistently transmits at 70,000 packets per second (or thereabouts) and no
more, in an otherwise identical scenario. This makes the results given by iperf
unexpectedly misleading in these situations (e.g. where the combination of
requested bandwidth and packet size requires high packet rates).
This behaviour was observed with the iperf packages from both wheezy and
unstable, built both with and without the included Debian patches.
* What exactly did you do (or not do) that was effective (or
ineffective)?
When running iperf 2.0.4 (built from the squeeze source package):
# iperf -u -c 127.0.0.1 -l 32 -b 1000M -t 60
------------------------------------------------------------
Client connecting to 127.0.0.1, UDP port 5001
Sending 32 byte datagrams
UDP buffer size: 224 KByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 53255 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 698 MBytes 97.6 Mbits/sec
[ 3] Sent 22886425 datagrams
In 60 seconds, 22886425 datagrams were generated, for an average of approx.
381440 packets per second. However while running iperf 2.0.5 included with
wheezy:
# iperf -u -c 127.0.0.1 -l 32 -b 1000M -t 60
------------------------------------------------------------
Client connecting to 127.0.0.1, UDP port 5001
Sending 32 byte datagrams
UDP buffer size: 224 KByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 39531 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 126 MBytes 17.7 Mbits/sec
[ 3] Sent 4144058 datagrams
Only 4144058 datagrams were generated in the same time period, averaging
approx. 69068 packets per second. This number seems to be a hard limit across
many machines, including a machine with dual 10-core Xeon processors.
The behaviour seen with 2.0.4 is the expected behaviour - that iperf generates
as many packets as possible given the hardware and so on on which it is run.
One hypothesis as to the cause of this problem is that the timing mechanism
used to generate the packets at the specified rate has changed between
versions, introducing this regression.
-- System Information:
Debian Release: 7.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages iperf depends on:
ii libc6 2.13-38+deb7u6
ii libgcc1 1:4.7.2-5
ii libstdc++6 4.7.2-5
iperf recommends no packages.
iperf suggests no packages.
-- no debconf information
all-iperf-output-across-versions.tar.gz
Description: GNU Zip compressed data
