Bob (Robert) McMahon | 5 Feb 18:10 2015

iperf2.0.9 plans

Hi,

 

Now that iperf 2.0.8 is out I’ve been getting requests for new features and bug fixes.  Here are my current plans:

 

o)  Support write error count to UDP client reports

o)  Add support for TTL information into server reports

o)  Add support for ToS information into server reports

o)  Fix –o (redirect to file) option

o)  Integrate simple IGMP/MLD querier into client to support testing v4/v6 multicast

o) Thoroughly test v6 and fix bugs found

o) Support new traffic option giving packet burst length, interburst gap, and interpacket gap

o) Come up with an analysis technique on the server to report how well the above is able to be reconstructed by the server app

 

Please feel free to contact me if other things are needed.  Also, if you have ideas on analyzing the traffic pattern per the above in a simple way, please share.

 

Bob McMahon

Broadcom Senior Principal SW Engineer, Wi-Fi Division

 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Kartik Kumar Perisetla | 29 Jan 04:34 2015
Picon

Regarding packet loss in UDP

Hi,

I am looking for a way to measure UDP packet loss between 2 hosts at a given bandwidth. 
I found I could leverage Mininet's iperf method to set l4type to UDP and set bandwidth. However, the response being returned isn't indicating anything about packet loss. 

So could someone please throw some light on how could I get packet loss in this scenario?

Thanks!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Steve Baillargeon | 27 Jan 17:48 2015
Picon

Public iperf 2 servers?

Hi

Does anyone know if there are any public servers supporting iperf2 (ideally iperf2.0.8)?

 

Any method to check the server iperf version remotely from the client?

 

Thank you

 

Steve B

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
ASHISH KUMAR Dhanotiya | 21 Jan 06:51 2015
Picon

Generating traffic

Is there any method through which I can generate traffic at specified time
Thank you
--
Ashish Kumar Dhanotiya

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bob (Robert) McMahon | 19 Jan 18:57 2015

Re: Generate ARP Packets

Hi Krati,

 

Iperf does not support sending ARP floods.  ARP is done by the kernel/os and not at the application/iperf layer and only is needed once to build the initial ARP cache.   This is all done underneath iperf.

 

You can issue arp clears per the destination ip of an active iperf stream to cause the kernel to rebuild the arp cache.  It’s doubtful that the clears can be done fast enough to meet your needs.

 

Bob

From: Krati Jain [mailto:krati24jain <at> gmail.com]
Sent: Monday, January 19, 2015 8:42 AM
To: iperf-users <at> lists.sourceforge.net
Subject: [Iperf-users] Generate ARP Packets

 

Hello,

I am working in Software Defined Networking(SDN). I have Opendaylight controller, and created virtual topology of hosts and switches using mininet(network simulator). I wish to generate huge traffic (send large number of packets one at a time)  in the network using iperf, so that controller is loaded.

The only packets which go to controller is ARP requests or whoes flows is not defined in switch.

How should I generate such packets using iperf?

Thanks,

-Krati

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Krati Jain | 19 Jan 17:41 2015
Picon

Generate ARP Packets

Hello,
I am working in Software Defined Networking(SDN). I have Opendaylight controller, and created virtual topology of hosts and switches using mininet(network simulator). I wish to generate huge traffic (send large number of packets one at a time)  in the network using iperf, so that controller is loaded.
The only packets which go to controller is ARP requests or whoes flows is not defined in switch.
How should I generate such packets using iperf?
Thanks,
-Krati
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bruce A. Mah | 9 Jan 19:25 2015
Picon

iperf-3.0.11 is available


ESnet (Energy Sciences Network) proudly announces the public release
of iperf-3.0.11.  This release includes a new -1 flag that causes the
iperf3 server to process one test and then exit (intended primarily
for integration with an upcoming release of bwctl).  A few other minor
fixes are included as well.

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

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

SHA256 hash:

e01db5be6f47f67c987463095fe4f5b8b9ff891fb92c39104d042ad8fde97f6e  iperf-3.0.11.tar.gz

iperf3 is freely-redistributable under a 3-clause BSD license.  More
information can be found in the LICENSE 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

Steve Baillargeon | 8 Jan 21:45 2015
Picon

iperf UDP burst mode

With minor corrections and new subject title:

·        1) we limit the configuration to burst size, packet size and gap indicating the number of UDP bytes/bits sent at each burst/gap

·        2) we limit the configuration of the burst size to a maximum reasonable value, say 50-100 packets

·        3) we limit the gap to me a minimum reasonable value, say 1 ms, 10 ms, 100 ms or 1 sec

·        4) we show the estimated peak bandwidth on the client side based on configured burst size, packet size and gap (if it is not possible to show actual BW)

·        5) we use always use the realtime option –z meaning we are hoping that each burst will be sent at line rate in most cases

·        6) we limit use case for Ethernet driver if wifi-driver is known to be problematic

 

-Steve B

 

From: Steve Baillargeon
Sent: January-08-15 3:37 PM
To: 'Bob (Robert) McMahon'
Cc: iperf-users <at> lists.sourceforge.net
Subject: RE: [Iperf-users] iperf 2.0.8beta

 

Hi Bob

Thank you for the detailed response!

 

Regardless of what is requested/configured by user, is there a way to measure/show the actual burst size and gap transmitted on the wire by the client?

 

What if we put “certain limits” on the client configuration and system performance, for instance:

 

·        1) we limit the configuration to burst size and packet size indicating the number of UDP bytes/bits sent at each burst

·        2) we limit the configuration of the burst size to a maximum reasonable value, say 50-100 packets

·        3) we limit the gap to me a minimum reasonable value, say 1 ms, 10 ms, 100 ms or 1 sec

·        4) we show the estimated peak bandwidth on the client side based on calculation from #1 and #2 (if it is not possible to show actual BW)

·        5) we use always use the realtime option –z meaning we are hoping that each burst will be sent at line rate in most cases

·        6) we limit use case for Ethernet driver if wifi-driver is known to be problematic

 

On the server side, we would also configure the test to be UDP burst mode with expected burst size.

I don’t know the content of the iperf2 UDP payload but I suspect it has a sequence number. Can you send me a description of the iperf UDP message content if it if possible? Then we could divide the sequence number in two parts: 1) burst number and 2)packet number in the burst. The server could just measure the number of packet loss for each burst and measure the received average bandwidth (burst) based on the total number of packets/bits received in-order . If received packets are out of order, then we could simplify the reporting and treat them as packet loss or preferably have a separate counter for it.

 

Regards

Steve B

 

From: Bob (Robert) McMahon [mailto:rmcmahon-dY08KVG/lbpWk0Htik3J/w@public.gmane.org]
Sent: January-08-15 2:48 PM
To: Steve Baillargeon
Cc: iperf-users <at> lists.sourceforge.net
Subject: RE: [Iperf-users] iperf 2.0.8beta

 

Hi Steve,

 

I considered adding a burst mode feature but didn’t do so because guaranteeing interpacket and interburst gaps at the application level is not certain for the following reasons:

 

o)  The delay call to create the gaps provides for an “at least” value.   For example, if the client requests a delay of 100 microseconds the OS guarantees that at least 100 microseconds of delay occurs.  But it could also be 10 milliseconds.  http://man7.org/linux/man-pages/man2/nanosleep.2.html

o)  The write call can suspend the thread causing an unexpected gap within the burst (though the –z or –realtime option can help with this)

o)  Application timing need not be preserved by the kernel nor network driver.  The underlying driver can aggregate write calls (very common in wi-fi drivers) losing application gap timing.

 

Since there is no way for the iperf client to know the actual gap(s) on the wire and because of the above, I decided adding support for bursts was sketchy and could mislead the user.

 

Also, in previous versions of iperf the code tried to preserve the minimum interpacket gap vs maintaining the requested UDP rate.  One can see this when running 2.0.5 where the actual transmit rate is slower than the requested rate.   We decided that was a poor choice, i.e. if the user asks for 100Mbs then the client should do its best to provide that load.   Since the gap delay calls are minimums it means that the client needs to speed up after a longer than then expected delay, effectively bursting for a short period allowing the client to converge on the requested (-b) transmit value.

 

With all that said, adding support for bursts is relatively easy to do.  The easiest way I can think of would be providing the burst size in the length (–l)  field, e.g. –l 1470/16 –b 100M which says the user would like a load of 100Mbs using 16  back to back writes of 1470 bytes (which is the UDP payload size.)    While adding the realtime option (-z) would help there could be no hard guarantee and no feedback to the user on the actual bursts and gaps.   Also, I am not sure if the goal of achieving the requested load loses priority to preserving bursts, i.e. don’t speed up when an application level burst delay is longer than expected.

 

Comments welcome and helpful,

 

Thanks,

Bob

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bob (Robert) McMahon | 8 Jan 20:47 2015

Re: iperf 2.0.8beta

Hi Steve,

 

I considered adding a burst mode feature but didn’t do so because guaranteeing interpacket and interburst gaps at the application level is not certain for the following reasons:

 

o)  The delay call to create the gaps provides for an “at least” value.   For example, if the client requests a delay of 100 microseconds the OS guarantees that at least 100 microseconds of delay occurs.  But it could also be 10 milliseconds.  http://man7.org/linux/man-pages/man2/nanosleep.2.html

o)  The write call can suspend the thread causing an unexpected gap within the burst (though the –z or –realtime option can help with this)

o)  Application timing need not be preserved by the kernel nor network driver.  The underlying driver can aggregate write calls (very common in wi-fi drivers) losing application gap timing.

 

Since there is no way for the iperf client to know the actual gap(s) on the wire and because of the above, I decided adding support for bursts was sketchy and could mislead the user.

 

Also, in previous versions of iperf the code tried to preserve the minimum interpacket gap vs maintaining the requested UDP rate.  One can see this when running 2.0.5 where the actual transmit rate is slower than the requested rate.   We decided that was a poor choice, i.e. if the user asks for 100Mbs then the client should do its best to provide that load.   Since the gap delay calls are minimums it means that the client needs to speed up after a longer than then expected delay, effectively bursting for a short period allowing the client to converge on the requested (-b) transmit value.

 

With all that said, adding support for bursts is relatively easy to do.  The easiest way I can think of would be providing the burst size in the length (–l)  field, e.g. –l 1470/16 –b 100M which says the user would like a load of 100Mbs using 16  back to back writes of 1470 bytes (which is the UDP payload size.)    While adding the realtime option (-z) would help there could be no hard guarantee and no feedback to the user on the actual bursts and gaps.   Also, I am not sure if the goal of achieving the requested load loses priority to preserving bursts, i.e. don’t speed up when an application level burst delay is longer than expected.

 

Comments welcome and helpful,

 

Thanks,

Bob

 

From: Steve Baillargeon [mailto:steve.baillargeon-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org]
Sent: Thursday, January 08, 2015 8:28 AM
To: Bob (Robert) McMahon
Subject: RE: [Iperf-users] iperf 2.0.8beta

 

Hi Bob

Thank you for the update!

 

Does iperf 2.x support the UDP burst mode usually found in nuttcp?

I did ask Bruce to verify if it is supported in iperf3.x (I think it is) but my question is now specific to iperf v2.

 

If iperf v2 does not support UDP bust mode, what is the best way to go about adding this enhancement?

 

Do you think the UDP bust mode will require a control connection between iperf client and server (to communicate test information between the actual test data exchange) which is not available with iperf v2? I don’t think such control connection is needed with UDP burst mode since we should be able to configure the server with the expected burst size and duration between bursts.

 

Regards

 

-Steve

 

From: Bob (Robert) McMahon [mailto:rmcmahon <at> broadcom.com]
Sent: December-18-14 2:31 PM
To: iperf-users <at> lists.sourceforge.net
Subject: [Iperf-users] iperf 2.0.8beta

 

Hi,

 

We are getting close to releasing iperf 2.0.8.   It’s been extensively used for our wi-fi testing as well as a little bit of 10G, but not much.   Please feel free to try it out and contact me about any issues.

 

https://sourceforge.net/projects/iperf2/

 

Below are the main differences from 2.0.5

  • Fix portability, compile and test with Linux, Win10, Win7, WinXP and MacOS, (possibly android)

  • Improved performance

  • Enhanced reporting with -e

  • Support smaller report intervals (5 ms or greater)

  • Support SO_RCVTIMEOUT for server reports regardless of no packets

  • Support SO_TIMESTAMP for kernel level packet timestamping

  • Support end/end latency in mean/min/max/stdev format (UDP) –e required

  • (assumes client and server clocks synched, e.g by Precision Time Protocol)

  • Add local port to bind support (-B option) using colon as separator

  • (e.g. iperf -c 192.168.100.100 -B 192.168.100.10:6001)

  • Support TCP rate limited streams (via the -b) using token bucket

  • Support packets per second (UDP) via pps as units, (e.g. -b 1000pps)

  • Display PPS in both client and server reports (UDP) (–e required)

  • Support realtime scheduler as a command line option (--realtime or –z, assumes proper user privileges)

  • Improve client tx code path so actual tx offered rate will converge to the -b value

  • Improve accuracy of microsecond delay calls (in platform independent manner)

  • (Use of Kalman filter to predict delay errors and adjust delays per predicted error)

  • Display target loop time in initial client header (UDP)

  • Fix final latency report sent from server to client (UDP)

  • Include standard deviation in latency output

  • Suppress unrealistic latency output (-/-/-/-)

  • Support SO_SNDTIMEO on send so socket write won't block beyond -t (TCP)

  • Use clock_gettime if available (preferred over gettimeofday())

  • TCP write and error counts (TCP retries and CWND for linux) (-e required)

  • TCP read count, TCP read histogram (8 bins) (-e required)

 

Thanks,

Bob McMahon

Broadcom Principal SW Engineer

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Robert Clove | 29 Dec 13:41 2014
Picon

Is iperf 3 code in c++?

Hi,

The iperf code hosted here https://github.com/esnet/iperf
Is it in c++?

Regards

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Bob (Robert) McMahon | 18 Dec 20:30 2014

iperf 2.0.8beta

Hi,

 

We are getting close to releasing iperf 2.0.8.   It’s been extensively used for our wi-fi testing as well as a little bit of 10G, but not much.   Please feel free to try it out and contact me about any issues.

 

https://sourceforge.net/projects/iperf2/

 

Below are the main differences from 2.0.5

  • Fix portability, compile and test with Linux, Win10, Win7, WinXP and MacOS, (possibly android)

  • Improved performance

  • Enhanced reporting with -e

  • Support smaller report intervals (5 ms or greater)

  • Support SO_RCVTIMEOUT for server reports regardless of no packets

  • Support SO_TIMESTAMP for kernel level packet timestamping

  • Support end/end latency in mean/min/max/stdev format (UDP) –e required

  • (assumes client and server clocks synched, e.g by Precision Time Protocol)

  • Add local port to bind support (-B option) using colon as separator

  • (e.g. iperf -c 192.168.100.100 -B 192.168.100.10:6001)

  • Support TCP rate limited streams (via the -b) using token bucket

  • Support packets per second (UDP) via pps as units, (e.g. -b 1000pps)

  • Display PPS in both client and server reports (UDP) (–e required)

  • Support realtime scheduler as a command line option (--realtime or –z, assumes proper user privileges)

  • Improve client tx code path so actual tx offered rate will converge to the -b value

  • Improve accuracy of microsecond delay calls (in platform independent manner)

  • (Use of Kalman filter to predict delay errors and adjust delays per predicted error)

  • Display target loop time in initial client header (UDP)

  • Fix final latency report sent from server to client (UDP)

  • Include standard deviation in latency output

  • Suppress unrealistic latency output (-/-/-/-)

  • Support SO_SNDTIMEO on send so socket write won't block beyond -t (TCP)

  • Use clock_gettime if available (preferred over gettimeofday())

  • TCP write and error counts (TCP retries and CWND for linux) (-e required)

  • TCP read count, TCP read histogram (8 bins) (-e required)

 

Thanks,

Bob McMahon

Broadcom Principal SW Engineer

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Gmane