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:rmcma...@broadcom.com]
Sent: January-08-15 2:48 PM
To: Steve Baillargeon
Cc: iperf-users@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
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
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:rmcma...@broadcom.com]
Sent: December-18-14 2:31 PM
To: iperf-users@lists.sourceforge.net<mailto:iperf-users@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
