RE: Iperf logging oddity on Linux with iperf 1.7.0
TCPdump shows a much more consistent rate *although there are a lot of retransmissions happening). The expected rate is about 10-50K depending on fluctuations in bw allocations on the wireless system.
I think this all goes back to iperf reports not being purely time based and the code not being able to properly detect when it is going to generate multiple reports at the same time and thus produce inaccurate reports for some intervals.
If I change the reporting interval to 10 seconds, this is less likely to happen and the TCP connections actually perform better (fewer retransmissions and better rate).
Paul
-----Original Message-----
From: Matthew J Zekauskas [mailto:matt --at-- internet2.edu]
Sent: Wednesday, March 10, 2004 7:30 PM
To: iperf-users --at-- dast.nlanr.net
Subject: Re: Iperf logging oddity on Linux with iperf 1.7.0
--On Wednesday, March 10, 2004 6:07 PM -0600 paul shields <pshields --at-- NAVINI.com> wrote:
> Below is a snippet of a log from a Linux server with the report interval set for 2 seconds and
> timestamps added as to exactly when iperf generated the line of output. The handling of time gaps
> seems incorrect. (notice timestamps are the same for some report intervals and all of the data
> rate is attributed to the fist interval print at that time. Iperf seems to want to "catch up" on
> the reporting process and generates a lot of false 0.0 output lines.
>
> The report should generate output for the combined 4-8 interval instead of creating two intervals
> and incorrectly reporting the data rate distribution between them.
>
> Comments?
> Paul
>
> 17:44:13 [ 18] local 172.27.2.28 port 5001 connected with 172.27.2.13 port 1215
> 17:44:16 [ 18] 0.0- 2.0 sec 12.8 KBytes 52.5 Kbits/sec
> 17:44:18 [ 18] 2.0- 4.0 sec 11.4 KBytes 46.7 Kbits/sec
> 17:44:23 [ 18] 4.0- 6.0 sec 2.85 KBytes 11.7 Kbits/sec
> 17:44:23 [ 18] 6.0- 8.0 sec 0.00 KBytes 0.00 Kbits/sec
> 17:44:27 [ 18] 8.0-10.0 sec 1.43 KBytes 5.84 Kbits/sec
> 17:44:27 [ 18] 10.0-12.0 sec 0.00 KBytes 0.00 Kbits/sec
> 17:44:30 [ 18] 12.0-14.0 sec 4.28 KBytes 17.5 Kbits/sec
> 17:44:30 [ 18] 14.0-16.0 sec 0.00 KBytes 0.00 Kbits/sec
> 17:44:32 [ 18] 16.0-18.0 sec 5.70 KBytes 23.4 Kbits/sec
> 17:44:37 [ 18] 18.0-20.0 sec 1.50 KBytes 6.16 Kbits/sec
> 17:44:37 [ 18] 20.0-22.0 sec 0.00 KBytes 0.00 Kbits/sec
> 17:44:41 [ 18] 22.0-24.0 sec 1.43 KBytes 5.84 Kbits/sec
> 17:44:41 [ 18] 24.0-26.0 sec 0.00 KBytes 0.00 Kbits/sec
> 17:44:41 [ 18] 26.0-28.0 sec 1.43 KBytes 5.84 Kbits/sec
> 17:44:44 [ 18] 28.0-30.0 sec 5.15 KBytes 21.1 Kbits/sec
I've seen something similar with iperf 1.7 as well as iperf 2 betas
when running under RH9 on gigE-connected systems. The bitrates
are quite a bit higher, but some runs have intervals that report
0 bits sent! Other runs are consistent at 980-ish Mb/s.
A related observation is that when I try to do 900 Mb/s UDP
streams, some runs are consistently right around 900 Mb/s,
and some runs also have intervals that report 0 bits sent.
In both of these cases, the intervals with data do not try
to "make up" for the missing bits; overall reports show
low bitrate transfers (usually 50 to 200 Mb/s for me :),
and no interval ever spikes above the physical maximum
bitrate. (What were you expecting in the runs you show?
is 0 bits sent over 2 seconds reasonable for you? Have
you tried any tcpdump or equivalent passive traces?)
I believe there may be an issue at the sender... alarms there
look like they are not delivered in time either. Maybe I've
got a bogus device driver? I haven't had time to pursue the
matter :(, instead choosing to filter out runs that look to
be completely bogus. This is not the correct long-term solution...
--Matt