Andrew Gallatin | 10 Sep 18:14 2014
Picon

gettimeofday

I was looking at the iperf3 source code, and its ... unfortunate ... that iperf3 still seems to be nearly as much of a gettimeofday() benchmark as it is a network benchmark.

For example, if I want to send UDP as fast as possible, I'll do something like:
iperf -c 172.18.126.63 -u -b 9999999M

If I use strace -c on this, I see:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.92    0.238950           1    287535           gettimeofday
 41.96    0.233611           3     71567           write
 14.87    0.082772           1     72900           select

The pattern seems to be:

gettimeofday
gettimeofday
select
gettimeofday
gettimeofday
write
gettimeofday
gettimeofday
select
<repeats>

This isn't a problem on *most* OSes (and it is getting better), but it can lead to surprisingly bad results on 10GbE or 40GbE networks on some OSes, especially one that chose an expensive timecounter (eg, one that does a PIO read access on every gettimeofday).  This is the big reason why I still use netperf.

Maybe iperf needs a "go fast" option that dispenses with all timing except to mark the time at the start & end of the test.

Drew

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bob (Robert) McMahon | 4 Sep 20:16 2014

Re: Difference In Jitter Calculations Between IPerf2 and IPerf3

Hi George,

That's a mistake on my end.  The client is the primary place I found SCHED_RR helpful.

I did commit this in the SVN repository and it's in the tar ball but didn't commit it in the git repository. 
That's fixed now and they all should be coherent.

Bob
-----Original Message-----
From: George Halpert [mailto:george <at> thesoniccloud.com] 
Sent: Thursday, September 04, 2014 12:26 AM
To: Bob (Robert) McMahon
Cc: iperf-users <at> lists.sourceforge.net; Jon Lederman
Subject: Re: [Iperf-users] Difference In Jitter Calculations Between IPerf2 and IPerf3

Hi Bob, 

Thanks for iperf 2.0.7 - lots of useful changes.

I'm curious, why didn't you also use SCHED_RR for the client thread?

Thanks,
George

----- Original Message -----
From: "Jon Lederman" <jonlederman <at> gmail.com>
To: "Bob (Robert) McMahon" <rmcmahon <at> broadcom.com>
Cc: iperf-users <at> lists.sourceforge.net, "George Halpert" <george <at> thesoniccloud.com>
Sent: Tuesday, September 2, 2014 11:47:23 PM
Subject: Re: [Iperf-users] Difference In Jitter Calculations Between IPerf2 and	IPerf3

Thanks for sending this.  Do you have any insights into the reasons for these differences.  We will send you
our results as well.
On Sep 2, 2014, at 5:20 PM, Bob (Robert) McMahon <rmcmahon <at> broadcom.com> wrote:

> Ok, I see different values as well.   Iperf2 is showing approximately 20 us jitter while iperf3 is showing
~150 us.  This is using a 200Mbs udp stream on 802.11 AC.
>  
> Bob
> From: Bob (Robert) McMahon [mailto:rmcmahon <at> broadcom.com] 
> Sent: Tuesday, September 02, 2014 1:34 PM
> To: Jon Lederman
> Cc: iperf-users <at> lists.sourceforge.net
> Subject: Re: [Iperf-users] Difference In Jitter Calculations Between IPerf2 and IPerf3
>  
> Don’t know but comments are ignored by the compiler ;)
>  
> Can you share your results?  I’d be curious to see the variation and if it could be related to things like
scheduling.  
>  
> Also, what os are you using?  If you are using linux you may want to set the processes to use SCHED_RR
>  
> http://www.cyberciti.biz/faq/howto-set-real-time-scheduling-priority-process/

>  
> I do that in iperf2
>  
> http://sourceforge.net/projects/iperf2/?source=directory

>  
> Bob
> From: Jon Lederman [mailto:jonlederman <at> gmail.com] 
> Sent: Tuesday, September 02, 2014 1:29 PM
> To: Bob (Robert) McMahon
> Cc: iperf-users <at> lists.sourceforge.net
> Subject: Re: [Iperf-users] Difference In Jitter Calculations Between IPerf2 and IPerf3
>  
> Thanks.  Look forward to your results.  Even though I also noticed that the calculation looks similar on the
surface, I did notice a comment in iperf3 to the effect:
>  
> // XXX: This is NOT the way to calculate jitter
>     //      J = |(R1 - S1) - (R0 - S0)| [/ number of packets, for average]
>  
> Any thoughts why that is in there?  The calculation in the code appears to have come directly out of the RFC 1889/3550.
>  
> Also, I want to clarify that this calculation seems to be average jitter not instantaneous jitter.  
>  
> Thanks.
>  
> -Jon
> On Sep 2, 2014, at 4:23 PM, Bob (Robert) McMahon <rmcmahon <at> broadcom.com> wrote:
>  
> 
> A quick cursory view of the source suggests the same calculation.  Let me run both on my test rig and see if I
get similar results.
> 
> Bob
> -----Original Message-----
> From: Jon Lederman [mailto:jonlederman <at> gmail.com] 
> Sent: Monday, September 01, 2014 5:22 PM
> To: iperf-users <at> lists.sourceforge.net
> Subject: [Iperf-users] Difference In Jitter Calculations Between IPerf2 and IPerf3
> 
> Hi,
> 
> In measuring jitter using Iperf 2.0.5 and Iperf 3, I have noticed a marked difference in the calculations
up to an order of magnitude.  Could you explain the differences in calculation of jitter between 2.0.5 and 3
and the accuracy.  Which should I rely upon?
> 
> Thanks in advance.
> 
> Jon
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/

> _______________________________________________
> Iperf-users mailing list
> Iperf-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
Jon Lederman | 2 Sep 02:21 2014
Picon

Difference In Jitter Calculations Between IPerf2 and IPerf3

Hi,

In measuring jitter using Iperf 2.0.5 and Iperf 3, I have noticed a marked difference in the calculations up
to an order of magnitude.  Could you explain the differences in calculation of jitter between 2.0.5 and 3
and the accuracy.  Which should I rely upon?

Thanks in advance.

Jon
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

eminem.adunanza | 29 Aug 16:47 2014

How to specify iperf exit port

Hi,
I currently use iperf to connect to a remote port on a remote host, i can obviously specify the remote port to connect to, 
but not the local one on which i exit on, for example i launch:

iperf -c remote_ip -u -p 4672 -w 64k -t 10

and i receive this:

------------------------------------------------------------
Client connecting to remote_ip, UDP port 4672
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte
------------------------------------------------------------
[  3] local local_ip port 20036 connected with remote_ip port 4672

as you can see it connect to udp://remote_ip:4672 using udp://local_ip:20036
how can i specify the local port, let say using local udp 4672 instead of local udp 20036?

thank oyu.

regards
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bruce A. Mah | 28 Aug 22:52 2014
Picon

iperf-3.0.7 is available [resend]


ESnet (Energy Sciences Network) proudly announces the public release
of iperf-3.0.7.  This version is a maintenance release with a several
fixes and enhancements.  Notable among these are fixes for a bug that
made it possible to disrupt existing, running tests and another bug
that caused problems with running iperf3 within perfSONAR.

More information on changes can be found in the RELEASE_NOTES
file in the source distribution.

iperf3 is a tool for measuring the maximum TCP and UDP performance
along a path, allowing for the tuning of various parameters and
reporting measurements such as throughput, jitter, and datagram packet
loss.

The original iperf was implemented by NLANR / DAST.  Version 3 is a
complete reimplementation, with the goals of a smaller, simpler code
base, and a library that can be used by other programs.  It also adds
new functionality, such as CPU utilization measurements, zero copy TCP
support, and JSON output.  Note that iperf3 clients and servers are
not compatible with, and will not interoperate with, earlier versions
of iperf.

iperf3 is fully supported on Linux, FreeBSD, and MacOS X.  It may run
on other platforms as well, although it has not received the same
attention and testing.

The source code for iperf 3.0.7 is available at:

http://downloads.es.net/pub/iperf/iperf-3.0.7.tar.gz

SHA256 hash:

49510e886f9e876cd73dcd80414bfb8c49b147c82125585e09c2a6e92369d3f2  iperf-3.0.7.tar.gz

iperf3 is freely-redistributable under a 3-clause BSD license.  More
information can be found in the LICENSING file inside the source
distribution.

Additional documentation for iperf3 can be found at:

http://software.es.net/iperf

More information about iperf3 (including the issue tracker, source
code repository access, and mailing list) can be found on the iperf3
page on GitHub at:

https://github.com/esnet/iperf

The mailing list for iperf3 development is:

iperf-dev@...

To see the list archives or join the mailing list, visit:

http://groups.google.com/group/iperf-dev

Martin T | 28 Aug 17:46 2014
Picon

How does Iperf 2.x client detect the amount of traffic it has sent?

Hi,

if one executes for example "iperf -c 178.62.60.141 -fm -b 100m -u -t
30 -i 10", then after each 10 second interval Iperf client prints out
the amount of data it has transferred in mebibytes:

root <at> vserver:~# iperf -c 178.62.60.141 -fm -b 100m -u -t 30 -i 10
WARNING: option -b implies udp testing
------------------------------------------------------------
Client connecting to 178.62.60.141, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 0.22 MByte (default)
------------------------------------------------------------
[  3] local 146.185.187.148 port 37660 connected with 178.62.60.141 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   119 MBytes   100 Mbits/sec
[  3] 10.0-20.0 sec   119 MBytes   100 Mbits/sec
[  3] 20.0-30.0 sec   119 MBytes   100 Mbits/sec
[  3]  0.0-30.0 sec   358 MBytes   100 Mbits/sec
[  3] Sent 255661 datagrams

Same is true for TCP. Fact, that transferred data and bandwidth are
printed out after the end of each interval and transferred data is
sometimes bit more or less than the bandwidth specified with the "-b"
flag, should mean that Iperf client actually somehow counts the sent
data and doesn't just print the argument of "-b" flag. Still, how does
Iperf client count the amount of data it sends? It sure doesn't do
this on some low level because if I introduce 10% packet loss with tc,
execute "iperf -c 178.62.60.141 -fm -b 100m -u -t 30 -i 10" and then
compare the packets Iperf client thought it sent(from Iperf client
output) with the amount of packets actually were put to wire(from "ip
-s link show dev eth0" output), then Iperf client thought that it sent
>250k datagrams while it actually did just bit over 230k. Exactly the
same holds true if I police the traffic with tc Token Bucket Filter
queuing discipline, i.e. according to Iperf client it has sent out
traffic at 100Mbps while actual traffic rate was policed by policer.

How does Iperf 2.x client detect the amount of traffic it has sent?
Does Iperf client simply count the packets it has passed to Linux
network stack? Could somebody point me to the place in source-code
where this takes place?

thanks,
Martin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Martin T | 22 Aug 11:49 2014
Picon

Re: Iperf client 2.0.5 shows unrealistic bandwidth results if Iperf server is unreachable

Hi,

> The report shall report  that the receiver did not see the generated packets.

The Iperf client reports this by saying that "WARNING: did not receive
ack of last datagram after 3 tries".
What I find weird are those unrealistic sent traffic results printed
by Iperf client. If I execute "iperf -c 10.10.10.1 -fm -t 600 -i60 -u
-b 500m" and 10.10.10.1 is firewalled/non-reachable, then I expect
output like this:

root <at> vserver:~#  iperf -c 10.10.10.1 -fm -t 600 -i60 -u -b 500m
------------------------------------------------------------
Client connecting to 10.10.10.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 0.22 MByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 38755 connected with 10.10.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  3613 MBytes   505 Mbits/sec
[  3] 60.0-120.0 sec  3620 MBytes   506 Mbits/sec
[  3] 120.0-180.0 sec  3618 MBytes   506 Mbits/sec
etc

In other words Iperf client should send traffic despite the fact that
10.10.10.1 is unreachable because UDP is connectionless and amount of
bandwidth sent should be ~500Mbps because this is determined during
the execution of client with the "-b" flag.

regards,
Martin

On 8/22/14, Sandro Bureca <sbureca@...> wrote:
> Hi, all,
> since udp is connection less by its nature, you may want to flood the
> network with iperf even
> with no correspondent receiver on the far end.
> The report shall report  that the receiver did not see the generated
> packets.
> Sandro
>
>
> On 22 August 2014 11:03, Martin T <m4rtntns@...> wrote:
>
>> Hi,
>>
>> please see the full output below:
>>
>> root <at> vserver:~# iperf -c 10.10.10.1 -fm -t 600 -i60 -u -b 500m
>> ------------------------------------------------------------
>> Client connecting to 10.10.10.1, UDP port 5001
>> Sending 1470 byte datagrams
>> UDP buffer size: 0.16 MByte (default)
>> ------------------------------------------------------------
>> [  3] local 192.168.1.2 port 55373 connected with 10.10.10.1 port 5001
>> [ ID] Interval       Transfer     Bandwidth
>> [  3]  0.0-60.0 sec  422744 MBytes   59104 Mbits/sec
>> [  3] 60.0-120.0 sec  435030 MBytes   60822 Mbits/sec
>> [  3] 120.0-180.0 sec  402263 MBytes   56240 Mbits/sec
>> [  3] 180.0-240.0 sec  398167 MBytes   55668 Mbits/sec
>> [  3] 240.0-300.0 sec  422746 MBytes   59104 Mbits/sec
>> [  3] 300.0-360.0 sec  381786 MBytes   53378 Mbits/sec
>> [  3] 360.0-420.0 sec  402263 MBytes   56240 Mbits/sec
>> [  3] 420.0-480.0 sec  406365 MBytes   56814 Mbits/sec
>> [  3] 480.0-540.0 sec  438132 MBytes   61395 Mbits/sec
>> [  3]  0.0-600.0 sec  4108674 MBytes   57443 Mbits/sec
>> [  3] Sent 6119890 datagrams
>> read failed: No route to host
>> [  3] WARNING: did not receive ack of last datagram after 3 tries.
>> root <at> vserver:~#
>>
>>
>> In case of UDP mode the Iperf client will send the data despite the
>> fact that the Iperf server is not reachable.
>>
>> Still, to me this looks like a bug. Iperf client reporting ~60Gbps
>> egress traffic on a virtual-machine with 1GigE vNIC while having
>> bandwidth specified with -b flag, is IMHO not expected bahavior.
>>
>>
>> regards,
>> Martin
>>
>>
>> On 8/22/14, Metod Kozelj <metod.kozelj@...> wrote:
>> > Hi,
>> >
>> > the bandwidth limitation switch (-b) limits the maximum rate with which
>> > sending party (that's usually client) will transmit data if there's no
>> > bottleneck that sending party is able to detect. If test is done using
>> TCP,
>> >
>> > bottleneck will be apparent to client (IP stack will always block
>> > transmission
>> > if outstanding data is not delivered yet). If test is done using UDP,
>> > sending
>> > party will mostly just transmit data at maximum rate except in some
>> > rare
>> > cases.
>> >
>> > To verify this, you can run iperf in client mode with command similar
>> > to
>> > this:
>> >
>> > iperf -c localhost -i 1 -p 42000 -u -b500M -t 10
>> >
>> > ... make sure that the port used in command above (42000) is not used
>> > by
>> > some
>> > other application. If you vary the bandwidth setting, you can se that
>> > there's
>> > a practical maximum speed that even loopback network device can handle.
>> When
>> >
>> > experimenting with the command above, I've found a few interesting
>> > facts
>> > about
>> > my particular machine:
>> >
>> >   * when targeting machine on my 100Mbps LAN, transmit rate would not
>> > go
>> >     beyond 96Mbps (which is consistent with the fact that 100Mmbps is
>> wire
>> >     speed while UDP over ethernet faces some overhead)
>> >   * when targeting loopback device with "low" bandwidth requirement
>> > (such
>> > as
>> >     50Mbps), transmit rate would be exactly half of requested. I don't
>> know
>> > if
>> >     this is some kind of reporting artefact or it actually does
>> > transmit
>> at
>> >     half the rate
>> >   * UDP transmit rate over loopback device would not go beyond 402Mbps.
>> >
>> > I was using iperf 2.0.5. And I found out that it behaves similarly on
>> > another
>> > host (402 Mbps max over loopback, up to 812 Mbps over GigE).
>> >
>> > Tests above show that loopback devices (and I would count any
>> > virtualised
>> > network devices as such) experience some kind of limits.
>> >
>> > Peace!
>> >    Mkx
>> >
>> > -- perl -e 'print
>> > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
>> > -- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
>> >
>> >
>> ------------------------------------------------------------------------------
>> >
>> > BOFH excuse #299:
>> >
>> > The data on your hard drive is out of balance.
>> >
>> >
>> >
>> > Martin T je dne 21/08/14 16:51 napisal-a:
>> >> Metod,
>> >>
>> >> but shouldn't the Iperf client send out traffic at 500Mbps as I had
>> >> "-b 500m" specified? In my example is prints unrealistic
>> >> bandwidth(~60Gbps) results.
>> >>
>> >>
>> >> regards,
>> >> Martin
>> >>
>> >> On 8/21/14, Metod Kozelj <metod.kozelj@...> wrote:
>> >>> Hi,
>> >>>
>> >>> Martin T je dne 21/08/14 15:12 napisal-a:
>> >>>> if I execute "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" and
>> >>>> 10.10.10.1 is behind the firewall so that Iperf client is not able
>> >>>> to
>> >>>> reach it, then I will see following results printed by Iperf client:
>> >>>>
>> >>>> [  ID]   Interval                Transfer
>> >>>> Bandwidth
>> >>>> [   3]   0.0 - 60.0 sec      422744 MBytes       59104 Mbits/sec
>> >>>> [   3]   60.0 - 120.0 sec  435030 MBytes       60822 Mbits/sec
>> >>>> etc
>> >>>>
>> >>>>
>> >>>> Why does Iperf client behave like that? Is this a know bug?
>> >>> That's not a bug in iperf, it's how UDP is working. The main
>> >>> difference
>> >>> between TCP and UDP is that with TCP, IP stack itself takes care of
>> >>> all
>> >>> the
>> >>>
>> >>> details (such as in-order delivery, retransmissions, rate adaption,
>> >>> ...),
>> >>> while with UDP stack that's responsibility of application. The only
>> >>> functionality that iperf application does when using UDP is to fetch
>> the
>> >>> server (receiving side) report at the end of transmission. Even this
>> >>> function
>> >>> is not performed in perfect way ... sending side only waits for
>> >>> server
>> >>> report
>> >>> for short time and if it filled network buffers, this waiting time
>> >>> can
>> >>> be
>> >>> too
>> >>> short.
>> >>>
>> >>> The same phenomenon can be seen if there's a bottleneck somewhere
>> >>> between
>> >>> the
>> >>> nodes and you try to push datarate too high ... routers at either
>> >>> side
>> >>> of
>> >>> the
>> >>> bottle will discard packets when their TX buffers get filled up. If
>> >>> TCP
>> >>> was
>> >>>
>> >>> used, this would trigger retransmission in IP stack and all of
>> >>> TCP-slow-start
>> >>> would kick in and sending application would notice drop in
>> >>> throughput.
>> >>> If
>> >>> UDP
>> >>> was used, IP stack would not react in any way and application would
>> dump
>> >>> data
>> >>> at top speed.
>> >>> --
>> >>>
>> >>> Peace!
>> >>>     Mkx
>> >>>
>> >>> -- perl -e 'print
>> >>> $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
>> >>> -- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>>
>> >>> BOFH excuse #252:
>> >>>
>> >>> Our ISP is having {switching,routing,SMDS,frame relay} problems
>> >>>
>> >>>
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Iperf-users mailing list
>> Iperf-users@...
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
>

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Martin T | 22 Aug 11:19 2014
Picon

How does Iperf server detect that the client has stopped transmitting and it should send the server report?

Hi,

if I execute "iperf -c 10.10.10.1 -fm -t 10 -u -b 50m", then am I
correct that the last datagram sent by the Iperf client includes a
special pattern which is an indication for Iperf server to send the
server report? First bytes of the last datagram should be like
ff:ff:fc:ac:53:f6:f1:57:00:04:93:b4,
ff:ff:ff:a9:53:f7:09:8e:00:0e:34:ac, etc while non-last datagrams
begin with bytes 00:00:00:53:53:f7:09:8e:00:0d:7c:ee,
00:00:00:03:53:f7:09:8d:00:0e:64:0f, etc.

thanks,
Martin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Martin T | 21 Aug 15:53 2014
Picon

Iperf client sends out less UDP traffic than determined with "-b" flag

Hi,

if I executed "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" in a
virtual-machine with GigE vNIC, then Iperf client(version 2.0.5) under
Debian sent traffic at 120Mbps during all the intervals. If I replaced
the OS in virtual-server with CentOS, the same Iperf release with the
same command was able to send traffic at 500Mbps. Does Iperf client
count packets it successfully manages to send and calculates the
amount of data sent by knowing the datagram size? What are the
theoretical possibilities to low bandwidth rate printed by Iperf
client other than very little CPU time(Iperf process is not able to
send out packets with sufficient rate)?

regards,
Martin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Martin T | 21 Aug 15:12 2014
Picon

Iperf client 2.0.5 shows unrealistic bandwidth results if Iperf server is unreachable

Hi,

if I execute "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" and
10.10.10.1 is behind the firewall so that Iperf client is not able to
reach it, then I will see following results printed by Iperf client:

[  ID]   Interval                Transfer                   Bandwidth
[   3]   0.0 - 60.0 sec      422744 MBytes       59104 Mbits/sec
[   3]   60.0 - 120.0 sec  435030 MBytes       60822 Mbits/sec
etc

Why does Iperf client behave like that? Is this a know bug?

thanks,
Martin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Martin T | 21 Aug 14:17 2014
Picon

transfered data and bandwidth in Iperf client output do not match

Hi,

after an Iperf test, I got following results:

[root <at>  ~]# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 0.04 MByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.2.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 0.01 MByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 32284 connected with 192.168.2.1 port 5001
[  3] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 52428
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  71.5 MBytes  10.0 Mbits/sec
[  4] Sent 51021 datagrams
[  4] Server Report:
[  4]  0.0-59.9 sec  69.8 MBytes  9.77 Mbits/sec   0.112 ms 1259/51020 (2.5%)
[  4]  0.0-59.9 sec  1 datagrams received out-of-order
[  3]  0.0-60.0 sec  69.8 MBytes  9.77 Mbits/sec   0.030 ms 1200/51021 (2.4%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order
[root <at>  ~]#

How did Iperf calculate, that it sent 71.5 MBytes? I mean it says it
has sent 51021 datagrams and one datagram is 1470B so I should have
sent 75MB instead(51021*1470/10^6). Or if I calculate transferred data
based on bandwidth, then it also shows 75Mbps(10/8*60). Or is the
transferred data pure data without the UDP and IP headers? If yes,
then transferred data size should still be more than 71.5MB..

regards,
Martin

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users


Gmane