<div dir="ltr">Hi All,<div><br></div><div>Please offer feedback per the following and please forward to relevant and interested parties.<br><br><b>Problem statement: </b>Network devices need to support and, hence, have tests for both high duty cycle and low duty cycle traffic scenarios. Iperf 2.1.1 is proposing two new options to support the latter.  >From the <a href="https://iperf2.sourceforge.io/iperf-manpage.html" target="_blank">man page</a>.<br><dl><dt style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><b>--burst-period[=</b><i>n</i><b>]</b></dt><dd style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium">Set the burst period in seconds. Defaults to one second. (Note: assumed use case is low duty cycle traffic bursts)</dd><dt style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><b>--burst-size[=</b><i>n</i><b>]</b></dt><dd style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium">Set the burst size in bytes. Defaults to 1M if no value is given.</dd></dl>Note that the burst-size is not the same as the -l value.  The former is an amount expected to be larger than the write size which is what -l specifies.<br><br>These settings will work for both UDP and TCP traffic (though UDP is yet to be coded up.)<br><br><b>Proposed server side output:<br></b><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>[rjmcmahon@localhost iperf2-code]$ iperf -s -e</div><div>------------------------------------------------------------</div><div>Server listening on TCP port 5001 with pid 28094</div><div>Read buffer size:  128 KByte (Dist bin width=16.0 KByte)</div><div>TCP window size:  128 KByte (default)</div><div>------------------------------------------------------------</div><div>[  1] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.113 port 59646 (MSS=1448) (<b style="background-color:rgb(255,242,204)">burst-period=2.00</b>) (trip-times) (sock=4) (peer 2.1.1-dev) on 2021-03-18 17:56:25 (PDT)</div><div>[ ID] Burst (start-end)  Transfer     Bandwidth       <b style="background-color:rgb(255,242,204)">XferTime</b>  <span style="background-color:rgb(255,242,204)"><b>(DC%) </b></span>    Reads=Dist          NetPwr</div><div>[  1] <b><span style="background-color:rgb(217,234,211)">0.0000-0.0092 sec </span> <span style="background-color:rgb(217,234,211)">1.00 MBytes  </span> <span style="background-color:rgb(217,234,211)">911 Mbits/sec</span>   <span style="background-color:rgb(217,234,211)">9.214 ms</span> <span style="background-color:rgb(217,234,211)">(0.46%)</span></b><span style="background-color:rgb(217,234,211)"> </span>   572=571:0:0:1:0:0:0:0  12</div><div>[  1] 2.0001-2.0092 sec  1.00 MBytes   921 Mbits/sec   9.105 ms (0.46%)    511=511:0:0:0:0:0:0:0  13</div><div>[  1] 4.0006-4.0098 sec  1.00 MBytes   914 Mbits/sec   9.180 ms (0.46%)    404=401:3:0:0:0:0:0:0  12</div><div>[  1] 6.0006-6.0099 sec  1.00 MBytes   898 Mbits/sec   9.338 ms (0.47%)    352=351:0:1:0:0:0:0:0  12</div><div>[  1] 8.0005-8.0097 sec  1.00 MBytes   904 Mbits/sec   9.276 ms (0.46%)    468=467:1:0:0:0:0:0:0  12</div><div>[  1] 0.0000-10.0022 sec  5.13 MBytes  4.30 Mbits/sec               2341=2334:5:1:1:0:0:0:0</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><br></blockquote><b>where XferTime </b>is the total time to transfer the burst. (With --trip-times this the first write time to the final read time. Without it it's the first read to the final read.)<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>and <b>DC is a Duty Cycle</b> calculation, i.e. XferTime/burst-period. Also note the Bandwidth calculation is computed per the xfer time,<br>i.e. packet or read/write events, and doesn't use as sample interval like -i does.</div></blockquote><div><br><b>Client side command for the above:</b><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><br></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>[rjmcmahon@ryzen3950 iperf2-code]$ src/iperf -c 192.168.1.10 <b style="background-color:rgb(255,242,204)">--burst-period=2.0 </b> --trip-times</div><div>------------------------------------------------------------</div><div>Client connecting to 192.168.1.10, TCP port 5001 with pid 29040 (1 flows)</div><div>Write buffer size: 131072 Byte</div><div>Bursting: 1.00 MByte every 2.00 seconds</div><div>TCP window size: 85.0 KByte (default)</div><div>------------------------------------------------------------</div><div>[  1] local 192.168.1.113%enp6s0 port 59646 connected with 192.168.1.10 port 5001 (MSS=1448) (trip-times) (sock=3) (ct=0.29 ms) on 2021-03-18 17:56:25 (PDT)</div><div>[ ID] Interval            Transfer    Bandwidth       Write/Err  Rtry     Cwnd/RTT        NetPwr</div><div>[  1] 0.0000-10.0107 sec  5.13 MBytes  4.29 Mbits/sec  43/0          0      127K/1590 us  338</div><div>[rjmcmahon@ryzen3950 iperf2-code]$</div></blockquote><div><br><b>Background:</b><br><br>Most iperf based testing has been high duty cycle or congested traffic. This allows one to measure things like peak average throughput.<br><br>Another aspect of network traffic is how devices respond to low periodic bursts. Things like WiFi aggregation may be impacted. Having precise support for low duty cycle, bursty traffic seems needed for more robust test scenarios.</div><div><br>The transmits are scheduled per <a href="https://linux.die.net/man/2/clock_nanosleep" target="_blank">clock_nanosleep</a> and done are a per traffic thread basis. (Things like -P will be supported.)<br><br>There are major differences in the server side output (client side output is TBD) per:</div><div><ol><li style="margin-left:15px">The timestamps are now burst based, start of burst to end of burst</li><li style="margin-left:15px">The burst size is displayed</li><li style="margin-left:15px">Bandwidth calculation is based on start of burst to end of burst and the burst size</li><li style="margin-left:15px">The burst transfer time is provided in units of milliseconds and resolution of microseconds</li><li style="margin-left:15px">A duty cycle output in percentage is provided as a convenience</li></ol>Note: applying the duty cycle to any specific resource is out of context of this proposal.  Basically, time is the resource used here.<br><br>Here is another run like above where the burst side is set to 10MBytes, notice the change in the output<br><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>[rjmcmahon@localhost iperf2-code]$ iperf -s -e</div></div><div><div>------------------------------------------------------------</div></div><div><div>Server listening on TCP port 5001 with pid 28516</div></div><div><div>Read buffer size:  128 KByte (Dist bin width=16.0 KByte)</div></div><div><div>TCP window size:  128 KByte (default)</div></div><div><div>------------------------------------------------------------</div></div><div><div>[  1] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.113 port 59722 (MSS=1448) (burst-period=2.00) (trip-times) (sock=4) (peer 2.1.1-dev) on 2021-03-18 18:09:33 (PDT)</div></div><div><div>[ ID] Burst (start-end)  Transfer     Bandwidth       XferTime  (DC%)     Reads=Dist          NetPwr</div></div><div><div>[  1] 0.0000-<span style="background-color:rgb(255,242,204)">0.0893 sec</span>  <span style="background-color:rgb(255,242,204)">10.0 MBytes </span>  940 Mbits/sec  <span style="background-color:rgb(255,242,204)">89.434</span> ms<span style="background-color:rgb(255,242,204)"> (4.5%)  </span>  6234=6233:0:1:0:0:0:0:0  1</div></div><div><div>[  1] 2.0004-2.0900 sec  10.0 MBytes   935 Mbits/sec  89.681 ms (4.5%)    6398=6397:1:0:0:0:0:0:0  1</div></div><div><div>[  1] 4.0003-4.0899 sec  10.0 MBytes   936 Mbits/sec  89.578 ms (4.5%)    6570=6570:0:0:0:0:0:0:0  1</div></div><div><div>[  1] 6.0004-6.0901 sec  10.0 MBytes   935 Mbits/sec  89.727 ms (4.5%)    6436=6436:0:0:0:0:0:0:0  1</div></div><div><div>[  1] 8.0004-8.0899 sec  10.0 MBytes   937 Mbits/sec  89.547 ms (4.5%)    5986=5985:1:0:0:0:0:0:0  1</div></div><div><div>[  1] 0.0000-10.0019 sec  50.1 MBytes  42.0 Mbits/sec               31686=31683:2:1:0:0:0:0:0<br><br>[rjmcmahon@ryzen3950 iperf2-code]$ src/iperf -c 192.168.1.10 --burst-period=2.0  --trip-times<b> --burst-size=10M</b><br>------------------------------------------------------------<br>Client connecting to 192.168.1.10, TCP port 5001 with pid 29299 (1 flows)<br>Write buffer size: 131072 Byte<br>Bursting: 10.0 MByte every 2.00 seconds<br>TCP window size: 85.0 KByte (default)<br>------------------------------------------------------------<br>[  1] local 192.168.1.113%enp6s0 port 59722 connected with 192.168.1.10 port 5001 (MSS=1448) (trip-times) (sock=3) (ct=0.38 ms) on 2021-03-18 18:09:33 (PDT)<br>[ ID] Interval            Transfer    Bandwidth       Write/Err  Rtry     Cwnd/RTT        NetPwr<br>[  1] 0.0000-10.0167 sec  50.1 MBytes  42.0 Mbits/sec  403/0          0      142K/516 us  10169<br><br></div></div></blockquote>Thanks for taking the time to read this and offering comments or suggestions. Also note that the <a href="https://sourceforge.net/projects/iperf2/" target="_blank">current code on the 2-1-1-dev branch</a> is in an early prototype phase with limited testing with no UDP support and client side output still a TBD.<font color="#888888"><br><br>Bob<br><div></div></font></div>

<br>
<span style="background-color:rgb(255,255,255)"><font size="2">This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.</font></span>