Yes, that's basically what I suggested. It would look something like
iperf -c 10.10.10.10 -b 100M -l 1470/16,32 -u where 16 is the min burst and
32 is the max
If one really doesn't want speed ups and doesn't care about converging on -b
then either:
iperf -c 10.10.10.10 -b 100M -l 1470/16 -u
or
iperf -c 10.10.10.10 -b 100M -l 1470/16,16 -u
Though, it's worth repeating, this will only control application level gaps.
If something below (os/driver) or an intermediate device (router/switch) clumps
them prior to the iperf server there would be no way of knowing, at least not
from the iperf client or server. This would be a best try type of solution
(with caveat emptor.)
Note: I believe a tool like an IXIA chassis can provide guarantees.
Bob
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
Sent: Thursday, January 08, 2015 2:18 PM
To: Bob (Robert) McMahon
Cc: iperf-users@lists.sourceforge.net
Subject: RE: [Iperf-users] iperf UDP burst mode
Hi Bob
I really think UDP burst mode with some well-understood expectations and
restrictions will be useful to test network BW and buffering capacity. What is
the next step to hopefully support it?
Regarding burst vs bandwidth configuration at the client. What if the user only
need to configure bandwidth (below client line rate), burst size and packet
size with some restrictions on the possible values. The client would then
estimate the gap to satisfy the bandwidth for a given train size (train is
probably maybe better than burst) and packet size. Is that what you suggested?
Regards
Steve
From: Bob (Robert) McMahon [mailto:rmcma...@broadcom.com]
Sent: January-08-15 4:57 PM
To: Steve Baillargeon
Cc: iperf-users@lists.sourceforge.net<mailto:iperf-users@lists.sourceforge.net>
Subject: RE: [Iperf-users] iperf UDP burst mode
I'm not sure switching to Ethernet will "fix" the issue nor that wi-fi is
problematic (each operates as expected given the physical medium.)
The core of the issue is that iperf is an application that hands packets (or
udp payloads) via write calls to the kernel. There is a network stack and a
driver between that and the wire. There are no rules per se that require
either of those to preserve application level timing. Also, there is no way
for the iperf client as an app to know physical wire xmit details. A tool
like wireshark connected to a mirrored switch port is probably the best way to
get an idea of what a wire looks like or, for wi-fi, a promiscuous mode device
near the iperf client.
I 'd prefer not to expose a minimum gap via the user cli unless it's really
needed as I think it's confusing particularly with the -b. But if there is a
real need it's not hard to add. In that context, the idea of limiting bursts
to a min/max might be the approach. The min/max would say, send at most max
packets before inserting the delay as defined by the minimum and the -b
requested rate. If the client is "at requested rate" then insert a gap after
minimum packets. If below requested rate, go to the maximum before inserting
the gap. Then the client code could add burst number and burst count in the
payload (per your suggestion), something like this is the 13th burst and 5th
packet in the 13th burst (where defining the time value delimiter between the
burst would be done by per the above min and -b.)
To your question of the current UDP payload, there is a microsecond timestamp
(taken from the client's clock) and a sequence number.
Note, the iperf client does show it's actual transmit rate though it's defined
by the speed the client writes packets from application level to the kernel's
network stack or, from an inverse perspective, how fast the OS accepts writes
from the client.
Bob
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
Sent: Thursday, January 08, 2015 12:46 PM
To: Bob (Robert) McMahon
Cc: iperf-users@lists.sourceforge.net<mailto:iperf-users@lists.sourceforge.net>
Subject: [Iperf-users] 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@lists.sourceforge.net<mailto:iperf-users@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
------------------------------------------------------------------------------
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
