RE: Iperf logging oddity on Linux with iperf 1.7.0
Paul,
This observation is something that we need to look into before pushing out
a 2.0 version. A fair amount of "code cleanup" was done between the 1.65
and 1.70 versions, and it appears this 'short interval' behavior has been
repeatable. Thanks for sending the report, along with the tidbit that
tcpdump was showing significant retransmissions. I'm guessing that that is
*not* the case for Matt's observations, however...?
-Jim
At 08:46 AM 3/11/2004 -0600, you wrote:
>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