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
