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

Sijo Joy | 12 Aug 20:56 2014
Picon

Iperf report interval granularity in milliseconds

Hi,

Iperf can report throughput in a step of 0.5 second (specified via - i option). Can it use a even smaller interval, such as in the order of milliseconds or 10 milliseconds? Is there any other tools which can reach that granularity? Thanks for your inputs in advance.

Best Regards,
Sijo
------------------------------------------------------------------------------
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bruce A. Mah | 28 Jul 21:03 2014
Picon

iperf-3.0.6 is available


ESnet (Energy Sciences Network) is proud to announce the public
release of iperf-3.0.6.  This version is a maintenance release with a
few bug fixes and enhancements, notably:

* Several problems with the -B option have been fixed.  Also, API
  calls have been added to libiperf to extend this functionality to
  API clients.

* Some portability fixes for OpenBSD and Solaris have been merged from
  the mainline.

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.6 is available at:

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

SHA256 hash:

3c5909c9b286b6503ffa141a94cfc588915d6e67f2aa732b08df0af73e21938b  iperf-3.0.6.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


Gmane