[Iperf-users] iperf 2.2.0 released

[Bob McMahon via Iperf-users]

Hi All,

iperf version 2.2.0 has been officially released.

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

iperf -v
iperf version 2.2.0 (10 April 2024) pthreads

Bob

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] Difference between InF and InP

[Bob McMahon via Iperf-users]

Hi All,

There is a subtle but important distinction between iperf 2's in
progress stats. One is called InF for in-flight and computed by taking the
stats from the stack. The second is called InP fo in-progress and taken by
computing the queue depth per Little's Law. The latter is e2e.  The
following two runs illustrate the differences.

First a run where there is a very large send side buffer and
TCP_NOTSENT_LOWAT is not used. In this case the send side socket buffer
should build up, which it does, and the e2e delay is seen per InP but not
InF. That's because InF is from the stack's view of the network while InP
is from the application view. Notice the InP is near the 100Mbytes socket
buffer size while the InF is about 1.5Mbytes

The second run sets TCP_NOTSENT_LOWAT and no the InF and InP are aligned at
about 1.5Mbytes

Run 1: No TCP_NOTSENT_LOWAT

rjmcmahon@fedora:~/Code/inflight/iperf2-code$ iperf -c 192.168.1.35
--trip-times -e -i 1 --sync-transfer-id -w 50m --tcp-write-prefetch 0

Client connecting to 192.168.1.35, TCP port 5001 with pid 240696 (1/0
flows/load)
Write buffer size: 131072 Byte
TCP congestion control using cubic
TOS set to 0x0 (dscp=0,ecn=0) (Nagle on)
TCP window size: 95.4 MByte (WARNING: requested 47.7 MByte)

[  1] local 192.168.1.103%enp4s0 port 44754 connected with 192.168.1.35
port 5001 (trip-times) (sock=3) (icwnd/mss/irtt=14/1448/176) (ct=0.24 ms)
on 2024-03-25 16:50:54.655 (PDT)
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
InF(pkts)/Cwnd/RTT(var)NetPwr
[  1] 0.00-1.00 sec   192 MBytes  1.61 Gbits/sec  1533/061
1538K(1088)/1555K/13234(110) us  15183
[  1] 1.00-2.00 sec  96.4 MBytes   808 Mbits/sec  771/0 0
1667K(1179)/1674K/14273(81) us  7080
[  1] 2.00-3.00 sec   128 MBytes  1.08 Gbits/sec  1026/0 0
1790K(1266)/1801K/15451(109) us  8704
[  1] 3.00-4.00 sec  96.2 MBytes   807 Mbits/sec  770/0 0
1859K(1315)/1875K/16008(84) us  6305
[  1] 4.00-5.00 sec   128 MBytes  1.08 Gbits/sec  1026/0 2
1340K(948)/1365K/11658(133) us  11535
[  1] 5.00-6.00 sec  96.2 MBytes   807 Mbits/sec  770/0 0
1409K(997)/1448K/12301(98) us  8205
[  1] 6.00-7.00 sec   128 MBytes  1.08 Gbits/sec  1026/0 0
1474K(1043)/1530K/13059(123) us  10298
[  1] 7.00-8.00 sec  96.2 MBytes   807 Mbits/sec  770/0 0
1534K(1085)/1575K/13494(111) us  7479
[  1] 8.00-9.00 sec   128 MBytes  1.08 Gbits/sec  1027/0 0
1602K(1133)/1614K/13807(132) us  9749
[  1] 9.00-10.00 sec  96.2 MBytes   807 Mbits/sec  770/0 0
1593K(1127)/1636K/13980(130) us  7219
[  1] 10.00-10.57 sec   128 KBytes  1.83 Mbits/sec  1/0 0
 0K(0)/1665K/14358(111) us  15.90
[  1] 0.00-10.57 sec  1.16 GBytes   941 Mbits/sec  9490/063
 0K(0)/1665K/14358(111) us  8193

root@rpi5-35:~# iperf -s -i 1 -e

Server listening on TCP port 5001 with pid 35250
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP congestion control default cubic
TCP window size:  128 KByte (default)

[  1] local 192.168.1.35%eth0 port 5001 connected with 192.168.1.103 port
44754 (trip-times) (sock=4) (peer 2.2.0-rc) (icwnd/mss/irtt=14/1448/182) on
2024-03-25 16:50:54.655 (PDT)
[ ID] IntervalTransferBandwidthBurst Latency
avg/min/max/stdev (cnt/size) inP NetPwr  Reads=Dist
[  1] 0.00-1.00 sec   112 MBytes   941 Mbits/sec
 451.474/1.878/839.327/236.465 ms (897/131093)  171 MByte 260
 22019=21972:11:11:8:0:2:2:13
[  1] 1.00-2.00 sec   112 MBytes   941 Mbits/sec
 709.032/560.182/839.576/80.886 ms (898/131052) 69.9 MByte 166
 22841=22836:3:2:0:0:0:0:0
[  1] 2.00-3.00 sec   112 MBytes   942 Mbits/sec
 690.533/559.994/839.511/79.692 ms (897/131201) 90.0 MByte 170
 18997=18993:4:0:0:0:0:0:0
[  1] 3.00-4.00 sec   112 MBytes   942 Mbits/sec
 708.975/559.939/839.014/80.667 ms (898/131063) 69.8 MByte 166
 19325=19325:0:0:0:0:0:0:0
[  1] 4.00-5.00 sec   112 MBytes   941 Mbits/sec
 689.814/559.899/838.858/79.718 ms (898/131053) 90.0 MByte 171
 19552=19552:0:0:0:0:0:0:0
[  1] 5.00-6.00 sec   112 MBytes   941 Mbits/sec
 709.082/559.756/838.974/80.714 ms (898/131053) 69.8 MByte 166
 19050=19030:4:0:0:1:0:1:14
[  1] 6.00-7.00 sec   112 MBytes   941 Mbits/sec
 690.027/559.817/839.295/79.776 ms (898/131050) 90.0 MByte 171
 19573=19570:2:1:0:0:0:0:0
[  1] 7.00-8.00 sec   112 MBytes   942 Mbits/sec
 709.150/560.197/839.131/80.593 ms (898/131056) 69.8 MByte 166
 20616=20608:4:3:1:0:0:0:0
[  1] 8.00-9.00 sec   112 MBytes   941 Mbits/sec
 690.031/560.092/839.122/79.848 ms (898/131050) 90.0 MByte 171
 18866=18864:2:0:0:0:0:0:0
[  1] 9.00-10.00 sec   112 MBytes   942 Mbits/sec
 709.217/560.065/838.999/80.484 ms (898/131056) 69.8 MByte 166
 18885=18882:2:1:0:0:0:0:0
[  1] 10.00-10.57 sec  64.0 MBytes   941 Mbits/sec
 

[Iperf-users] iperf 2-2-0-rc (release candidate)

[Bob McMahon via Iperf-users]

Hi All,

iperf 2 has a release candidate ready for users to try. It's on sourceforge
 as iperf 2-2-0-rc. Please file
tickets on sourceforge  as well.

Release notes:

2.2.0 (as of March 14th, 2024
--
o new ./configure --enable-summing-debug option to help with summing debug
o select ahead of writes slow down UDP performance. support ./configure
--disable-write-select
o support fo -b 0 with UDP, unlimited load or no delay between writes
o support for --sync-transfer-id so client and server will match the ids
and give a remap message
o support --dscp command line option
o support for application level retries and minimum retry interval of the
TCP connect() syscall via --connect-retry-time and --connect-retry-timer,
repsectively
o support for --ignore-shutdown so test will end on writes vs the BDP drain
and TCP close/shutdown, recommended not to use this but in rare cases
o support for --fq-rate-step and --fq-rate-step-interval
o CCAs per --tcp-cca, --tcp-congestion, etc neeed to be case sensitive
o support for both packets and bytes inflight taken from tcp_info struct
amd pkt calc of (tcp_info_buf.tcpi_unacked - tcp_info_buf.tcpi_sacked -
tcp_info_buf.tcpi_lost + tcp_info_buf.tcpi_retrans)
o man page updates and -h to reflect new options, better descriptions
o lots of work around summing with parallel threads, new implementation
based on interval or slot counters, hopefully should work reliably
o --bounceback tests are much more reliable and robust
o Improve event handling around select timeouts, helps with larger -P
values and summing
o use the getsockopt IP_TOS for the displayed output, warn when set and get
don't match
o better tos byte output, include dscp and ecn fields individually
o better tos setting code for both v6 and v4, so they behave the same
around checks and warnings
o much better NULL events to help with reporter processing even when
traffic is not flowing
o support for a new string report
o python flows work around CDF based tests
o rate limit fflush calls to a max of one every millisecond or 1000 per sec
o remove superfulous fflush calls
o reports when P = 1 and --sum-only need sum outputs
o enable summing with --incr-dstip
o add macro TIME_GET_NOW to set a struct timeval in a portable manner
o code readability improvements with enums, bools, etc.
o fix for TCP rate limited and -l less than min burst size
o only use linux/tcp.h when absolutely needed, otherwise use netinet/tcp.h
o print bounceback OWD tx/rx in interval reports
o add flows Makefiles for tarball or make dist-all
o support interval reports for bounceback histograms
o support for TCP working loads and UDP primary flows, including UDP
isochronous, per ticket 283
o fix working-load with isoch so working-load streams are capacity seeking
o exit when CCA not supported or read of the current CCA doesn't match
requested CCA
o add more make check tests
o add support for omit string (omit code not ready for this release)
o pyflows qdisc settings and outputs
o add first send pacing with --tx-starttime so listener threads udp_accept
has time to perform udp_accept() between the client threads
o adjust the sender time per the client delay and the client first write,
i.e. subtract out this delay in the calculations
o fixes for small packets and --tx-starttime
o use more modern multicast socket options (now in
src/iperf_multicast_api.c)
o warn on bind port not sent with --incr-srcport
o display fq-rate values in outputs when --fq-rate is used
o add support for --test-exchange-timeout
o fixes around wait_tick
o add support for TCP_TX_DELAY via --tcp-tx-delay  option on both
client and server
o pass the CCA from client to server
o support burst-size with different write sizes and don't require
--burst-period
o output traffic thread send scheduling error stats in final ouput
o output clock unsync stats with --bounceback
o add warn message on MSG_CTRUNC
o UDP select fixes
o enable TCP_NOTSENTLOWAT and set to a default small value with
--tcp-write-times
o default histogram max binning to 10 seconds
o add a max timestamp to histogram outputs so user can find packets in
pcaps or equivalent
o autoconf change for struct ip_mreqn
o print errno on writen fail

-- 
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 

Re: [Iperf-users] Threading and CPU affinity in iperf2/iperf3

[Bob McMahon via Iperf-users]

Hi Bruce,

We do -c localhost testing to help isolate performance issues too. I think
there are a few classes of bottlenecks that you and your team are aware of:

   - Core frequencies or cycle times, i.e. cpu limits
   - On chip accesses, including L1/L2 cache accesses
   - Pin i/o access, off chip but on board or CPU package, e.g. L3 cache
   and pcie bus memory
   - Network i/o accesses

It seems a bit of an art to find what is driving performance. I tried to
warn when network i/o is not driving a test's limits but not sure how good
my mechanism is so I don't really promote it much.

Bob

On Tue, Sep 26, 2023 at 10:25 AM Bruce A. Mah  wrote:

> Hrm, no not doing zero-copy.
>
> We probably need to do some more testing to try to nail this stuff down a
> bit. The latest results we've been seeing (not by me personally) are less
> clear. I'll let the people who were actually doing this testing (or are
> closer to it) chime in if and when they feel like it.
>
> Anyways, I was mostly wondering when I started this thread if there's
> something obvious that we're missing. It doesn't sound like there is.
>
> I think running iperf2 or iperf3 from within numactl should be good for
> giving the needed CPU pinning functionality...I think anyways.
>
> Thanks!
>
> Bruce.
>
> If memory serves me right, Bob McMahon wrote:
>
> Iperf2 doesn't support zero copy. Are your tests using that? Did you try
> Iperf2 on your system? I can add an affinity option if you find it
> helpful.
>
> Bob
>
> On Mon, Sep 25, 2023, 7:14 AM Bruce A. Mah  wrote:
>
>> Thanks Bob! Yes the effects of CPU affinity were new to us before testing
>> the multi-threading code. At least that's when I started noticing their
>> effects (or rather, a couple colleagues pointed this out to me). This
>> coincided with us getting results from some different test environments, so
>> it might be that we're just running in some new regime and thus seeing
>> effects that were hidden to us before.
>>
>> Bruce.
>>
>> If memory serves me right, Bob McMahon wrote:
>>
>> I should note that I mostly test on WiFi networks or 10G. There may be
>> improvements on 100G+ with CPU affinity and I just haven't tried it.
>>
>> Bob
>>
>> On Fri, Sep 22, 2023, 10:52 AM Bob McMahon 
>> wrote:
>>
>>> Hi Bruce,
>>>
>>> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on
>>> cores. I tried to use CPU affinity a few years ago and I didn't notice any
>>> performance impact. I was kinda of surprised by this. I have no idea why
>>> there is different behavior between 2 & 3 per this.
>>>
>>> Bob
>>>
>>> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah  wrote:
>>>
>>>> Hey Bob--
>>>>
>>>> As we're doing some testing of the multi-threaded iperf3 in various
>>>> environments, we've observed (not surprisingly) that CPU pinning of threads
>>>> can have a significant impact on the throughput of tests. Generally we're
>>>> running on some recent Ubuntu distribution of Linux.
>>>>
>>>> I'm trying to understand a report that iperf2 seems to automatically Do
>>>> The Right Thing (tm) with respect to getting threads on the right CPU cores
>>>> (particularly on multiple CPU package systems). But by contrast, good
>>>> performance with iperf3 needs either the -A option for CPU affinity or
>>>> running iperf3 within an invocation of numactl. I haven't yet had the
>>>> opportunity to experiment with iperf2 much in this kind of environment.
>>>>
>>>> Is there some magic that iperf2 does to automatically figure out a good
>>>> placement for the threads it spawns? I've looked through the source code
>>>> (in particular compat/Thread.c) but I can't find anything applicable. I'd
>>>> love to do something similar, if indeed this exists, in iperf3.
>>>>
>>>> Thanks!
>>>>
>>>> Bruce.
>>>>
>>>
>> 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,

Re: [Iperf-users] Threading and CPU affinity in iperf2/iperf3

[Bob McMahon via Iperf-users]

Iperf2 doesn't support zero copy. Are your tests using that? Did you try
Iperf2 on your system? I can add an affinity option if you find it helpful.

Bob

On Mon, Sep 25, 2023, 7:14 AM Bruce A. Mah  wrote:

> Thanks Bob! Yes the effects of CPU affinity were new to us before testing
> the multi-threading code. At least that's when I started noticing their
> effects (or rather, a couple colleagues pointed this out to me). This
> coincided with us getting results from some different test environments, so
> it might be that we're just running in some new regime and thus seeing
> effects that were hidden to us before.
>
> Bruce.
>
> If memory serves me right, Bob McMahon wrote:
>
> I should note that I mostly test on WiFi networks or 10G. There may be
> improvements on 100G+ with CPU affinity and I just haven't tried it.
>
> Bob
>
> On Fri, Sep 22, 2023, 10:52 AM Bob McMahon 
> wrote:
>
>> Hi Bruce,
>>
>> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on
>> cores. I tried to use CPU affinity a few years ago and I didn't notice any
>> performance impact. I was kinda of surprised by this. I have no idea why
>> there is different behavior between 2 & 3 per this.
>>
>> Bob
>>
>> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah  wrote:
>>
>>> Hey Bob--
>>>
>>> As we're doing some testing of the multi-threaded iperf3 in various
>>> environments, we've observed (not surprisingly) that CPU pinning of threads
>>> can have a significant impact on the throughput of tests. Generally we're
>>> running on some recent Ubuntu distribution of Linux.
>>>
>>> I'm trying to understand a report that iperf2 seems to automatically Do
>>> The Right Thing (tm) with respect to getting threads on the right CPU cores
>>> (particularly on multiple CPU package systems). But by contrast, good
>>> performance with iperf3 needs either the -A option for CPU affinity or
>>> running iperf3 within an invocation of numactl. I haven't yet had the
>>> opportunity to experiment with iperf2 much in this kind of environment.
>>>
>>> Is there some magic that iperf2 does to automatically figure out a good
>>> placement for the threads it spawns? I've looked through the source code
>>> (in particular compat/Thread.c) but I can't find anything applicable. I'd
>>> love to do something similar, if indeed this exists, in iperf3.
>>>
>>> Thanks!
>>>
>>> Bruce.
>>>
>>
> 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.
>
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Threading and CPU affinity in iperf2/iperf3

[Bob McMahon via Iperf-users]

I should note that I mostly test on WiFi networks or 10G. There may be
improvements on 100G+ with CPU affinity and I just haven't tried it.

Bob

On Fri, Sep 22, 2023, 10:52 AM Bob McMahon  wrote:

> Hi Bruce,
>
> Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on
> cores. I tried to use CPU affinity a few years ago and I didn't notice any
> performance impact. I was kinda of surprised by this. I have no idea why
> there is different behavior between 2 & 3 per this.
>
> Bob
>
> On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah  wrote:
>
>> Hey Bob--
>>
>> As we're doing some testing of the multi-threaded iperf3 in various
>> environments, we've observed (not surprisingly) that CPU pinning of threads
>> can have a significant impact on the throughput of tests. Generally we're
>> running on some recent Ubuntu distribution of Linux.
>>
>> I'm trying to understand a report that iperf2 seems to automatically Do
>> The Right Thing (tm) with respect to getting threads on the right CPU cores
>> (particularly on multiple CPU package systems). But by contrast, good
>> performance with iperf3 needs either the -A option for CPU affinity or
>> running iperf3 within an invocation of numactl. I haven't yet had the
>> opportunity to experiment with iperf2 much in this kind of environment.
>>
>> Is there some magic that iperf2 does to automatically figure out a good
>> placement for the threads it spawns? I've looked through the source code
>> (in particular compat/Thread.c) but I can't find anything applicable. I'd
>> love to do something similar, if indeed this exists, in iperf3.
>>
>> Thanks!
>>
>> Bruce.
>>
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Threading and CPU affinity in iperf2/iperf3

[Bob McMahon via Iperf-users]

Hi Bruce,

Iperf 2 doesn't support CPU affinity. It lets the OS schedule threads on
cores. I tried to use CPU affinity a few years ago and I didn't notice any
performance impact. I was kinda of surprised by this. I have no idea why
there is different behavior between 2 & 3 per this.

Bob

On Fri, Sep 22, 2023 at 10:29 AM Bruce A. Mah  wrote:

> Hey Bob--
>
> As we're doing some testing of the multi-threaded iperf3 in various
> environments, we've observed (not surprisingly) that CPU pinning of threads
> can have a significant impact on the throughput of tests. Generally we're
> running on some recent Ubuntu distribution of Linux.
>
> I'm trying to understand a report that iperf2 seems to automatically Do
> The Right Thing (tm) with respect to getting threads on the right CPU cores
> (particularly on multiple CPU package systems). But by contrast, good
> performance with iperf3 needs either the -A option for CPU affinity or
> running iperf3 within an invocation of numactl. I haven't yet had the
> opportunity to experiment with iperf2 much in this kind of environment.
>
> Is there some magic that iperf2 does to automatically figure out a good
> placement for the threads it spawns? I've looked through the source code
> (in particular compat/Thread.c) but I can't find anything applicable. I'd
> love to do something similar, if indeed this exists, in iperf3.
>
> Thanks!
>
> Bruce.
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf 2 as older perception (was Re: iperf3 Security Advisory ESNET-SECADV-2023-0002)

[Bob McMahon via Iperf-users]

No worries Bruce. Thanks for the correction.  I'm older too so maybe being
called older isn't really a bad thing ;)

I do think many users will learn each tool's feature set based upon their
needs. Having two similar open source tools with some
overlapping capabilities, e.g. to measure throughput or capacity, is a good
thing for all. If one suspects the tool they can try the other one.

I do think some core properties which both tools support are:

   - capacity measurements with CWND & RTT sampling (iperf2 requires -e)
   - --fq-rate based source pacing
   - support for threads

Note: There may be a move towards TCP CCAs that support source pacing, as
network hosts evolve from as fast as possible (AFAP) towards congestion
mitigation, to help eliminate standing queues or bufferbloat. I've added
some --fq-rate options that might be applicable to the iperf 3 user base -
not sure.

The iperf 2 pacing options include the below as well as supporting the CCA
per client side only setting of --tcp-cca which get passed to the server
(CCA's like prague need it set on both ends for the L4S ECN support.)

*--tcp-cca*Set the congestion control algorithm to be used for TCP
connections. (same as --tcp-congestion)
*--fq-rate **n*[kmgKMG]Set a rate to be used with fair-queuing based
socket-level pacing, in bytes or bits per second. Only available on
platforms supporting the SO_MAX_PACING_RATE socket option. (Note: Here the
suffixes indicate bytes/sec or bits/sec per use of uppercase or lowercase,
respectively)*--fq-rate-step **n*[kmgKMG]Set a step of rate to be used with
fair-queuing based socket-level pacing, in bytes or bits per second. Step
occurs every fq-rate-step-interval (defaults to one second)
*--fq-rate-step-interval **n*Time in seconds before stepping the fq-rate



On Fri, Sep 15, 2023 at 1:35 PM Bruce A. Mah  wrote:

> I've corrected our advisory and sent out a new version.
>
> Once again, sorry for giving the wrong impression. I believe this comes
> from a copy-and-paste of some much earlier text that was written before you
> started actively maintaining iperf2 (that does not excuse the error, but
> that's probably why it happened).
>
> Bruce.
>
> I wrote:
>
> > Hi Bob--
> >
> > Apologies! The text "older version" wasn't right and didn't even
> contribute any value in the context where it was used. I'm not sure how
> that phrase got included, but that mistake is definitely mine.
> >
> > Thanks for the update on iperf2 activities. We've been working on adding
> multi-threading capabilities to iperf3, so that it can use multiple CPU
> cores for higher throughput testing. (Of course, iperf2 has had this
> ability for quite awhile.) We've done a few public betas over the summer,
> with generally useful and favorable results. The plan is to bring this into
> a mainline release "soon".
> >
> > Bruce.
> >
> > If memory serves me right, Bob McMahon wrote:
> >
> >> Thanks for this Bruce & to the iperf 3 team.
> >>
> >> A small correction - not sure I'd say iperf2 is an older version but
> rather
> >> another version based from the original iperf code (using those design
> >> patterns.) The latest version for iperf 2 is version 2.1.9 released on
> >> March 14, 2023. One can always compile the bleeding edge from source per
> >> the master branch. Those commits come in spurts but can be daily. Some
> new
> >> multicast code was committed yesterday as an example.
>
> [snip]
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] Iperf 2 as older perception (was Re: iperf3 Security Advisory ESNET-SECADV-2023-0002)

[Bob McMahon via Iperf-users]

Thanks for this Bruce & to the iperf 3 team.

A small correction - not sure I'd say iperf2 is an older version but rather
another version based from the original iperf code (using those design
patterns.) The latest version for iperf 2 is version 2.1.9 released on
March 14, 2023. One can always compile the bleeding edge from source per
the master branch. Those commits come in spurts but can be daily. Some new
multicast code was committed yesterday as an example.

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

Iperf 2 has new releases about once per year but the master branch is
always current and contains the latest commits. We may release a 2.2.0
within the next few months per new features, e.g. around working-loads and
dual CCAs (amongst others) and bug fixes, and after our standard testing
cycle which takes up to one month. My hope is to release 2.2.0 by the end
of 2023.

I notice a lot of open source distributions are way behind in the iperf2
versions bundled. It may be helpful if engineers in positions to influence
open source packagings become aware of iperf 2 and now newer versions are
generally better both in features and bug fixes. Also the WiFi alliance
(WFA)  seems to be standardizing on iperf 2.1.9 for
latency related verifications.

Thanks,
Bob

On Thu, Sep 14, 2023 at 12:38 PM Bruce A. Mah  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> ESnet Software Security Advisory
> ESNET-SECADV-2023-0002
>
> Topic:  iperf3 Server Denial of Service
> Issued: 13 September 2023
> Credits:Jorge Sancho Larraz (Canonical)
> Affects:iperf-3.14 and earlier
> Corrected:  iperf-3.15
>
> I.  Background
>
> iperf3 is a utility for testing network performance using TCP, UDP,
> and SCTP, running over IPv4 and IPv6.  It uses a client/server model,
> where a client and server communicate the parameters of a test,
> coordinate the start and end of the test, and exchange results.  This
> message exchange takes place over a TCP "control connection".
>
> II.  Problem Description
>
> The iperf3 server and client will, at various times, send data over
> the control connection that control the parameters, start and stop of
> a test, and result exchange. Many of these data have some expected
> length to them (whether fixed or variable).
>
> It is possible for a malicious or malfunctioning client to send less
> than the expected amount of data to the server. If this happens, the
> server will hang indefinitely waiting for the remainder (or until the
> connection gets closed). Because iperf3 is deliberately designed to
> service only one client connection at a time, this will prevent other
> connections to the iperf3 server.
>
> III.  Impact
>
> A malicious or misbehaving process can connect to an iperf3 server and
> prevent other connections to the server indefinitely. This issue
> mainly applies to an iperf3 server that is reachable from some
> untrusted host or network, such as the public Internet. It might be
> possible for a malicious iperf3 server to mount a similar attack on an
> iperf3 client.
>
> iperf2, an older version of the iperf utility, uses a different model
> of interaction between client and server, and is not affected by this
> issue.
>
> IV.  Workaround
>
> There is no workaround for this issue, however as best practice
> dictates, iperf3 should not be run with root privileges, to minimize
> possible impact. Note that iperf3 was not designed to be a
> long-running server on the public Internet.
>
> V.  Solution
>
> Update iperf3 to a version containing the fix (i.e. iperf-3.15 or
> later).
>
> VI.  Correction details
>
> The bug causing this vulnerability has been fixed by the following
> commit in the esnet/iperf Github repository:
>
> master  5e3704dd850a5df2fb2b3eafd117963d017d07b4
>
> All released versions of iperf3 issued on or after the date of this
> advisory incorporate the fix.
>
> ESnet would like to thank Jorge Sancho Larraz (Canonical) for bringing
> this issue to our attention.
>
> Security concerns with iperf3 can be submitted privately by sending an
> email to the developers at .
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmUDTk0ACgkQSYSRCoyq
> 7opD6wgAurQ/02J1AQEedE8dR47h3/HdpU4BwA+ZrI/xsatauRAjfZy+33jWYmVd
> nQFD2pDu/Xi86ha0xUsvj8g7Qx2tJNEvhQuYVkkCu6Z5SSKQo5UTobWqudHhA6z4
> EcBptDR4erSQ/IScTSpSe97Vsi8zC9Oc2t+DJxMRNW8otHkieg/kw8Yeh6ekhJWA
> gcBZ/Fw8usI+G0vOyZD6PVqgRNdH5tCH7Pz3hqaWu/jhQK47fwvUIv/CG0MfKKEl
> OOAGeIONq62QKOnVlHgRt6dD7gITMy9CDkb7mqBbLdZVuFRGsmu1zJba25TYQKFI
> NLQqwFiCvQsLxc5Bs8TqJBrSyjyaRQ==
> =wCGb
> -END PGP SIGNATURE-
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential 

Re: [Iperf-users] Traffic generation using Iperf3 in Mininet

[Bob McMahon via Iperf-users]

I can't speak to mininet nor iperf 3 but iperf2 supports python 3's asyncio
for this type of use. It's in the flows directory. It requires password
less ssh for control pipes.

https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/

Bob

On Tue, Aug 8, 2023, 7:36 AM poriya rinkal  wrote:

> Hello everyone,
>
> I hope you all are doing well. Apologies for the long post.
>
> I am Rinkal, currently writing my masters thesis. I have a query related
> to traffic generation using iperf3 in Mininet. This might not be entirely
> related to iperf but i am in need of a solution as I am not able to
> understand what actually is the problem.
>
> For the background:
> I have a custom mininet topology (the code is given below) which is
> running with ryu controller and I need to send traffic from all hosts to a
> single server to analyze the throughput and delay parameters.
>
> I am running ryu controller using command : ryu-manager
> ryu.app.simple_switch_stp_13 ryu.app.ofctl_rest
> and mininet custom topology using command : sudo mn --custom ./ryu/topo.py
> --topo=mytopo --mac --link=tc --switch ovs,protocols=OpenFlow13
> --controller remote
>
> Everything is pinging and running fine. Using xterm I have tried to send
> traffic to the server host in the topology from all the hosts(mobile
> stations) at the same time using iperf3 in mininet but unfortunately I am
> not able to do it as the second host does not send the traffic when the
> first one is sending. I did try it without giving any bandwidth on the
> links but it is still the same.
>
> If someone can help me through this it would be a great help in my thesis.
> I will be extremely grateful. Please find the code below.
>
> Best Regards
> Rinkal Poriya
>
>
> Mininet Custom Topology Code :
>
> from mininet.net import Mininet
> from mininet.topo import Topo
> from mininet.link import TCLink
> from mininet.node import Controller, OVSSwitch, UserSwitch,
> RemoteController
> from mininet.log import setLogLevel, info
>
> class MyTopo( Topo ):
>
> def __init__( self ):
>
> Topo.__init__( self )
>
> H1 = self.addHost( 'MS1', ip="10.0.0.1", mac='00:00:00:00:00:aa')
> H2 = self.addHost( 'MS2', ip="10.0.0.2", mac='00:00:00:00:00:bb')
> H3 = self.addHost( 'MS3', ip="10.0.0.3", mac='00:00:00:00:00:cc')
> H4 = self.addHost( 'MS4', ip="10.0.0.4", mac='00:00:00:00:00:dd')
> H5 = self.addHost( 'MS5', ip="10.0.0.5", mac='00:00:00:00:00:ee')
> H6 = self.addHost( 'MS6', ip="10.0.0.6", mac='00:00:00:00:00:ff')
> H7 = self.addHost( 'MS7', ip="10.0.0.7", mac='00:00:00:00:00:gg')
> H8 = self.addHost( 'MS8', ip="10.0.0.8", mac='00:00:00:00:00:hh')
> H9 = self.addHost( 'MS9', ip="10.0.0.9", mac='00:00:00:00:00:ii')
> H10 = self.addHost('MS10', ip="10.0.0.10", mac='00:00:00:00:00:jj')
>
> server = self.addHost('server', ip="10.0.0.100",
> mac='00:00:00:00:00:kk')
>
> b1 = self.addSwitch( 'bts1', cls=OVSSwitch,
> mac='00:00:00:00:00:01')
> b2 = self.addSwitch( 'bts2', cls=OVSSwitch,
> mac='00:00:00:00:00:02')
> b3 = self.addSwitch( 'bts3', cls=OVSSwitch,
> mac='00:00:00:00:00:03')
> b4 = self.addSwitch( 'bts4', cls=OVSSwitch,
> mac='00:00:00:00:00:04')
> b5 = self.addSwitch( 'bts5', cls=OVSSwitch,
> mac='00:00:00:00:00:05')
>
>
> s1 = self.addSwitch('s1', dpid='6001', cls=OVSSwitch,
> mac='00:00:00:00:00:06')
> s2 = self.addSwitch('s2', dpid='7001', cls=OVSSwitch,
> mac='00:00:00:00:00:07')
> s3 = self.addSwitch('s3', dpid='8001', cls=OVSSwitch,
> mac='00:00:00:00:00:08')
> s4 = self.addSwitch('s4', dpid='9001', cls=OVSSwitch,
> mac='00:00:00:00:00:09')
> s5 = self.addSwitch('s5', dpid='1010', cls=OVSSwitch,
> mac='00:00:00:00:00:10')
>
> s0 = self.addSwitch('s0', dpid='', cls=OVSSwitch,
> mac='00:00:00:00:00:11')
> s6 = self.addSwitch('s6', dpid='1212', cls=OVSSwitch,
> mac='00:00:00:00:00:12')
>
>
> self.addLink( H1, b1, cls=TCLink, bw=15)
> self.addLink( H2, b1, cls=TCLink, bw=15)
> self.addLink( H3, b2, cls=TCLink, bw=15)
> self.addLink( H4, b2, cls=TCLink, bw=15)
> self.addLink( H5, b3, cls=TCLink, bw=15)
> self.addLink( H6, b3, cls=TCLink, bw=15)
> self.addLink( H7, b4, cls=TCLink, bw=15)
> self.addLink( H8, b4, cls=TCLink, bw=15)
> self.addLink( H9, b5, cls=TCLink, bw=15)
> self.addLink( H10, b5, cls=TCLink, bw=15)
>
> self.addLink( b1, b2, cls=TCLink, bw=20)
> self.addLink( b2, b3, cls=TCLink, bw=20)
> self.addLink( b3, b4, cls=TCLink, bw=20)
> self.addLink( b4, b5, cls=TCLink, bw=20)
> self.addLink( b5, b1, cls=TCLink, bw=20)
>
> self.addLink(b1, s1, cls=TCLink, bw=40)
> self.addLink(b2, s2, cls=TCLink, bw=40)
> self.addLink(b3, s3, cls=TCLink, bw=40)
> self.addLink(b4, s4, cls=TCLink, bw=40)
> self.addLink(b5, s5, 

Re: [Iperf-users] Bandwidth: what am I measuring?

[Bob McMahon via Iperf-users]

Don't forget to test responsiveness and latency too. Bandwidth is only one
metric. Lots of apps are being slowed per latency not throughput. Think of
latency as the limiting speed of causality which is mostly independent of
channel capacity.

The new bounceback feature will be released in 2.1.9.  It's currently in
the 2.1.9-rc (release candidate)

Bob

On Sun, Feb 19, 2023 at 2:47 PM Pieter Hulshoff  wrote:

> On 19-02-2023 17:39, Bob McMahon wrote:
>
> It's end to end at the socket layer, writes and reads. So it's the
> transport layer payload. The transport layer cab be either TCP or UDP with
> iperf 2. Iperf 3 also carries SCP.
>
> The lower layers, e.g. IP & ethernet frames are not part of the
> calculation. Those don't typically go to socket or app layer.
>
> https://man7.org/linux/man-pages/man2/socket.2.html
>
>
> Thank you; that should help me to interpret the bandwidth numbers I get.
>
> Kind regards,
>
> Pieter Hulshoff
>
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Bandwidth: what am I measuring?

[Bob McMahon via Iperf-users]

It's end to end at the socket layer, writes and reads. So it's the
transport layer payload. The transport layer cab be either TCP or UDP with
iperf 2. Iperf 3 also carries SCP.

The lower layers, e.g. IP & ethernet frames are not part of the
calculation. Those don't typically go to socket or app layer.

https://man7.org/linux/man-pages/man2/socket.2.html

Bob

On Sun, Feb 19, 2023, 5:50 AM Pieter Hulshoff  wrote:

> Hello all,
>
> When I'm running iperf bandwidth tests, what exactly am I configuring
> (-b) / measuring (displayed results)?
> UDP/TCP payload?
> IP payload (UDP/TCP data)?
> Ethernet payload (IP data)?
> Ethernet data?
>
> Kind regards,
>
> Pieter Hulshoff
>
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2.1.9 release candidate

[Bob McMahon via Iperf-users]

Hi All,

The iperf 2.1.9 release candidate
 is out. If
possible, please test and report bugs
.

Thanks,
Bob

2.1.9 (as of February 13th, 2023)
--
o --bounceback officially supported (including Windows) for
repsonsiveness test scenarios
o deprecated --bounceback-congest introduced in 2.1.8 with --working-loads
o --working-loads supports is generalized; works with --bounce-back,
--connect-only & --burst-period
o default TCP_NOTSENT_LOWAT with the --working-loads concurrent traffic
o add support for GMT time formatting via --utc option
o --trip-times will auto set TCP_NOTSENT_LOWAT
o CSV output fixes for reverse
o CSV output regressions fixed per sum outputs using negative transfer ids
o CSV output support with --enhanced
o Fix to isoch wait_tick with Windows
o fix support for --txstart-time with --bounceback
o Add support for summing histograms in histogram sum outputs
o Multiple sum report fixes per threading where needing mutex protections
o Jitter packet IPG calcluations ignore inter frame gaps
o Isoch jitter output to use running value vs sampled value
o Add support for --jitter-histograms
o man page content updates
o output isoch scheduling errors at end of isoch run
o PRIdMAX fix for ARM systems
o better work around in isochronous with Windows per early return of
WaitForSingleObject()
o fix SO_BINDTODEVICE regression
o fix v6 source port parsing with -B and brackets
o fix malloc error with --hideips
o fixes for rate limited TCP with --trip-times
o add support for TCL_NOTSENT_LOWAT with rate limited TCP
o permit key now supports -P using listen() with a backlog, no longer
single threaded limit
o fixes for zero valued permit-key
o fixes for multiple permit-key regressions
o fix token bucket delay wiht TCP await write
o fix isMulticast test for ipv4 - previous logic indicate true for
240.x.x.x which is not multicast
o fix regression on jitter calc - starts on second transit time
o add cmsg for loop with UDP rx timestamp, cmsg processing best to use
loop w/test
o use stdout and exit(0) for -h and -v (vs stderr and exit(1))
o add python facetime scripts
o Fix single thread compile breakage
o fix windows cross compile
o multiple spelling error fixes in comments and man page

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf real-time speed data display

[Bob McMahon via Iperf-users]

Thanks for this. Let me look at it a bit. It may be good to integrate it
into the iperf 2 flows code.


Bob



On Sat, Jan 28, 2023 at 3:22 AM shi7631470  wrote:

> I wrote a python script  using matplotlib to display the iperf real-time
> speed data.
> Share it,  hope helpful.
> It is simple and works well.
>
> iperf_plt.py :  main python script
> speed.sh :  iperf setting script
> iperf_view.png:  UI screenshot
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] UDP Datagram Count

[Bob McMahon via Iperf-users]

Sorry, not a direct answer, but what version of iperf are you running? This
looks like output from iperf 3.

Bob

PS. One might want to try iperf 2 
as well. I'd suggest -e or --enhanced for more informative reports. This is
only for iperf 2.


On Thu, Sep 22, 2022 at 2:41 PM Jason Martin  wrote:

> I'm having some trouble interpreting the UDP test results and was
> wondering if someone could correct/guide me?
>
> I am using all the defaults and connecting from the client to the server
> using UDP. I am confused because it looks like the client is sending 16
> datagrams per second for 10 seconds, a total of 160 datagrams. However, the
> server and client indicate that only 159 were sent/received, and 0 were
> lost.
>
>
> Client results:
> [ ID] Interval   Transfer Bandwidth   Total Datagrams
> [  4]   0.00-1.01   sec   128 KBytes  1.04 Mbits/sec  16
> [  4]   1.01-2.01   sec   128 KBytes  1.06 Mbits/sec  16
> [  4]   2.01-3.01   sec   128 KBytes  1.04 Mbits/sec  16
> [  4]   3.01-4.01   sec   128 KBytes  1.05 Mbits/sec  16
> [  4]   4.01-5.01   sec   128 KBytes  1.04 Mbits/sec  16
> [  4]   5.01-6.01   sec   128 KBytes  1.06 Mbits/sec  16
> [  4]   6.01-7.01   sec   128 KBytes  1.04 Mbits/sec  16
> [  4]   7.01-8.01   sec   128 KBytes  1.06 Mbits/sec  16
> [  4]   8.01-9.01   sec   128 KBytes  1.04 Mbits/sec  16
> [  4]   9.01-10.01  sec   128 KBytes  1.05 Mbits/sec  16
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth   JitterLost/Total
> Datagrams
> [  4]   0.00-10.01  sec  1.25 MBytes  1.05 Mbits/sec  9.575 ms  0/159 (0%)
>
>
> Server results:
> [ ID] Interval   Transfer Bandwidth   JitterLost/Total
> Datagrams
> [  5]   0.00-1.01   sec   104 KBytes   846 Kbits/sec  12.745 ms  0/13 (0%)
> [  5]   1.01-2.00   sec   144 KBytes  1.18 Mbits/sec  19.201 ms  0/18 (0%)
> [  5]   2.00-3.00   sec   112 KBytes   921 Kbits/sec  17.153 ms  0/14 (0%)
> [  5]   3.00-4.00   sec   136 KBytes  1.11 Mbits/sec  16.183 ms  0/17 (0%)
> [  5]   4.00-5.00   sec   128 KBytes  1.05 Mbits/sec  19.292 ms  0/16 (0%)
> [  5]   5.00-6.00   sec   136 KBytes  1.11 Mbits/sec  17.524 ms  0/17 (0%)
> [  5]   6.00-7.00   sec   128 KBytes  1.05 Mbits/sec  15.414 ms  0/16 (0%)
> [  5]   7.00-8.00   sec   128 KBytes  1.05 Mbits/sec  12.795 ms  0/16 (0%)
> [  5]   8.00-9.01   sec   128 KBytes  1.04 Mbits/sec  12.340 ms  0/16 (0%)
> [  5]   9.01-10.00  sec   128 KBytes  1.06 Mbits/sec  9.575 ms  0/16 (0%)
> [  5]  10.00-10.08  sec  0.00 Bytes  0.00 bits/sec  9.575 ms  0/0 (0%)
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth   JitterLost/Total
> Datagrams
> [  5]   0.00-10.08  sec  0.00 Bytes  0.00 bits/sec  9.575 ms  0/159 (0%)
>
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation

[Bob McMahon via Iperf-users]

How about something like 'Iperf Next Evolution 2022 (iperf2)
<https://sourceforge.net/projects/iperf2/>'

I'm very open to better suggestions.

Thanks,
Bob

On Tue, Aug 16, 2022 at 1:04 PM Sebastian Moeller  wrote:

> Ho Bob,
>
> +1 for renaming; the iperf2 iperf3 things is really confusing for mere end
> users.
>
> However "next generation/NG" is a relative moniker, in a few years NG is
> going to be the new normal and hence the name misleading again.
>
> While somewhat lame, maybe "iperformance" might be better in side stepping
> the-bigger-is-better issue when including numbers in the name, or obviously
> the correct answer go directly to iperf42 ;)
>
> Regards
> Sebastian
>
>
> > On Aug 16, 2022, at 20:54, Bob McMahon via Make-wifi-fast <
> make-wifi-f...@lists.bufferbloat.net> wrote:
> >
> > Hi All,
> >
> > It's unfortunate that numbers have been used in iperf naming. Many think
> iperf3 is the next version of iperf (or iperf2.)  The number in the name
> isn't a version number as iperf 2 and iperf 3 are different code bases,
> different developers, have different goals, and don't interoperate.
> >
> > I'm thinking it's a good time to break this number as part of the name
> and only use -v for version numbers. In that context, I'm thinking about
> renaming iperf 2 to iperf next generation. The "next generation" implies
> that are lots of new features around responsiveness and latency.
> >
> > This proposed name will be used in web sites, etc. The "iperf2" binary
> will still just be iperf. I'm also hoping to get an IANA service as 'iperf'
> that way any device that supports the iperf 2.1.8 can also advertise
> responsiveness support.
> >
> > Here is an example and proposed updates to sourceforge. My hope is that
> this will help clear up the confusion between the two different tools.
> >
> > Comments?
> > Bob
> >
> > 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.___
> > Make-wifi-fast mailing list
> > make-wifi-f...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] comments on renaming iperf 2 to iperf next generation

[Bob McMahon via Iperf-users]

Hi All,

It's unfortunate that numbers have been used in iperf naming. Many think
iperf3 is the next version of iperf (or iperf2.)  The number in the name
isn't a version number as iperf 2 and iperf 3 are different code bases,
different developers, have different goals, and don't interoperate.

I'm thinking it's a good time to break this number as part of the name and
only use -v for version numbers. In that context, I'm thinking about
renaming iperf 2 to iperf next generation. The "next generation" implies
that are lots of new features around responsiveness and latency.

This proposed name will be used in web sites, etc. The "iperf2" binary will
still just be iperf. I'm also hoping to get an IANA service as 'iperf' that
way any device that supports the iperf 2.1.8 can also advertise
responsiveness support.

Here is an example and proposed updates to sourceforge.
 My hope is that this will help
clear up the confusion between the two different tools.

Comments?
Bob

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2 responsiveness test in 2.1.8-rc, --bounceback option

[Bob McMahon via Iperf-users]

Hi All,

I've added a low impact, low duty cycle responsiveness test to iperf 2.  Man
page is here. 

[rjmcmahon@bobcat iperf2-code]$ iperf -v
iperf version 2.1.8-rc (6 August 2022) pthreads

[rjmcmahon@bobcat iperf2-code]$ iperf -s --permit-key=mytest  -P 1
--hide-ips

Server listening on TCP port 5001
TCP window size:  128 KByte (default)
Permit key is 'mytest' (timeout in 20.0 seconds)


[rjmcmahon@ryzen3950 iperf2-code]$ iperf -c hostname -i 1 --bounceback
--permit-key=mytest --hide-ips

Client connecting to (**hidden**), TCP port 5001
Bursting:  100 Byte writes 10 times every 1.00 second(s)
Bounce-back test (size= 100 Byte) (server hold req=0 usecs)
TCP window size: 16.0 KByte (default)

[mytest(1)] local *.*.*.96 port 38048 connected with *.*.*.123 port 5001
(bb len/hold=100/0) (icwnd/mss/irtt=14/1448/15038)
[ ID] IntervalTransferBandwidth BB
cnt=avg/min/max/stdev Rtry  Cwnd/RTTRPS
[mytest(1)] 0.00-1.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.333/9.247/15.596/2.493 ms0   14K/11667 us88 rps
[mytest(1)] 1.00-2.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=10.164/9.340/13.791/1.417 ms0   14K/10374 us98 rps
[mytest(1)] 2.00-3.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.301/9.321/14.310/2.010 ms0   14K/10796 us88 rps
[mytest(1)] 3.00-4.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.242/9.432/14.401/2.128 ms0   14K/10720 us88 rps
[mytest(1)] 4.00-5.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.576/9.558/14.442/2.196 ms0   14K/10821 us86 rps
[mytest(1)] 5.00-6.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.310/9.514/14.615/2.151 ms0   14K/10806 us88 rps
[mytest(1)] 6.00-7.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=10.944/9.310/14.490/2.233 ms0   14K/10548 us91 rps
[mytest(1)] 7.00-8.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.584/9.468/19.286/3.254 ms0   14K/10794 us86 rps
[mytest(1)] 8.00-9.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=10.987/9.378/14.322/2.139 ms0   14K/10533 us90 rps
[mytest(1)] 9.00-10.00 sec  1.95 KBytes  16.0 Kbits/sec
 10=11.449/9.930/14.722/2.151 ms0   14K/10832 us87 rps
[mytest(1)] 0.00-10.03 sec  19.5 KBytes  15.9 Kbits/sec
 100=11.189/9.247/19.286/2.190 ms0   14K/11083 us89 rps
[  1] 0.00-10.03 sec BB8(f)-PDF:
bin(w=100us):cnt(100)=93:1,94:9,95:5,96:11,97:9,98:2,99:5,100:6,101:9,102:3,103:3,104:1,105:1,106:2,107:1,115:1,129:1,130:1,132:1,137:1,138:2,139:3,141:4,142:2,143:4,144:3,145:4,147:2,148:1,156:1,193:1
(5.00/95.00/99.7%=94/147/193,Outliers=0,obl/obu=0/0)

Bob

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Measuring latency with iperf3 instead of iperf2

[Bob McMahon via Iperf-users]

Iperf 2 site has a man page. Make install will install the man page per the
latest version. You'll want to compile from source for bounceback. Branch
of master or 2-1-8-rc has that code. It will be generally released with
2.1.8 when that's complete and fully tested.

https://iperf2.sourceforge.io/iperf-manpage.html

https://sourceforge.net/p/iperf2/code/ci/master/tree/doc/CLOCKSYNC_NOTES

Bob

On Sat, Jul 16, 2022, 1:07 AM Ohad Vano  wrote:

> I am interested in measuring network latency over TCP connection.
> Where can I find documentation for these flags? (such as the --boundback
> or --trip-times)
> Can't find these on the iperf website documentation.
>
> Ohad
>
>
> On Sat, Jul 16, 2022 at 12:40 AM Bob McMahon 
> wrote:
>
>> "IPerf 2 <https://sourceforge.net/projects/iperf2/> is different from
>> the iperf3 <https://github.com/esnet/iperf>. Each can be used to measure
>> network performance, however, they DO NOT interoperate. They are completely
>> independent implementations with different strengths, different options,
>> and different capabilities. Both are under active development"
>>
>> iperf 2 latency & one way delay (OWD) results are reliable assuming one
>> has synchronized the clocks to a common reference.  Tests such as
>> --bounceback don't require clock sync as it uses a TCP round trip
>> measurement, i.e. write() to read() and back.
>>
>> Bob
>>
>> On Fri, Jul 15, 2022 at 1:16 PM Ohad Vano  wrote:
>>
>>> Hi,
>>>
>>> I can't find a way to measure latency over TCP using iperf3. I think
>>> that this feature is supported in iperf2. Why isn't this supported in
>>> iperf3? Are the iperf2 results reliable?
>>>
>>> Thanks,
>>> Ohad
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>
>> 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.
>
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Measuring latency with iperf3 instead of iperf2

[Bob McMahon via Iperf-users]

"IPerf 2  is different from the
iperf3 . Each can be used to measure
network performance, however, they DO NOT interoperate. They are completely
independent implementations with different strengths, different options,
and different capabilities. Both are under active development"

iperf 2 latency & one way delay (OWD) results are reliable assuming one has
synchronized the clocks to a common reference.  Tests such as --bounceback
don't require clock sync as it uses a TCP round trip measurement, i.e.
write() to read() and back.

Bob

On Fri, Jul 15, 2022 at 1:16 PM Ohad Vano  wrote:

> Hi,
>
> I can't find a way to measure latency over TCP using iperf3. I think that
> this feature is supported in iperf2. Why isn't this supported in iperf3?
> Are the iperf2 results reliable?
>
> Thanks,
> Ohad
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Hardware Requirements for Iperf Server

[Bob McMahon via Iperf-users]

I can speak to iperf 2 but not iperf 3.

It depends on the goals. If the goal is to test throughput only, then the
hardware requirements are driven by the ability to saturate the link under
test. If the links are 10G or above, and speaking for iperf 2, the -P
option will use multiple traffic threads so more cores will help.

If the goals include measuring one way delay (OWD) then the hardware needs
a way to synchronize the system clocks to a common reference. We use the
GPS atomic clock since it's somewhat available over the globe.

In general, iperf users (and blog authors) are behind. We find that latency
really needs attention from the industry at large. Seems like too few
understand this aspect of network performance (and user experience) and
seem to be stuck on throughput-only measurements.

Bob

On Wed, Jun 29, 2022 at 11:37 AM ChenWei Hung 
wrote:

> Hello,
>
> We are trying to set up our own Iperf server for speed testing. What are
> the hardware requirements for Iperf server?
>
>
>
> Thank you,
>
>
>
> Chen-Wei
>
> *ChenWei Hung *
> Intern - Network Technician
>
> Office:
> chenwei.h...@midco.com
>
> *Midco.com*
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2: RPM w/working load, tos symbolic support

[Bob McMahon via Iperf-users]

I've added a few more options to the iperf 2 bounceback test around
responsiveness & working load.

CLIENT SPECIFIC OPTIONS

   --bounceback
  run a tcp bounceback test (set size with -l or --len,
defaults to 100 bytes)

   --bounceback-congest[=up|down|bidir][,n]
  request a concurrent working load or TCP stream(s), defaults
to full duplex (or bidir) unless the up or down option is provided. The
number of TCP streams defaults to 1 and
  can  be  changed  via the n value, e.g.
--bounceback-congest=down,4 will use four TCP streams from server to the
client as the working load. The IP ToS will be BE (0x0) for
  working load traffic.

Also, thanks to Dave Taht and some WMM QoS guys, I've added symbolic names
to the --tos and --tos-override support.

   IP  tos:  Specifies  the type-of-service or DSCP class for
connections.  Accepted values are af11, af12, af13, af21, af22, af23, af31,
af32, af33, af41, af42, af43, cs0, cs1, cs2,
   cs3, cs4, cs5, cs6, cs7, ef, le, nqb, nqb2, ac_be, ac_bk, ac_vi,
ac_vo, lowdelay, throughput, reliability, a numeric value, or none to use
the operating system default.  The ac_xx
   values are the four access categories defined in WMM for Wi-Fi, and
they are aliases for DSCP values that will be mapped to the corresponding
ACs under the assumption that the de‐
   vice uses the DSCP-to-UP mapping table specified in IETF RFC 8325.

Thanks,
Bob

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Port iperf in server mode

[Bob McMahon via Iperf-users]

You may want to use iperf3 for this. Iperf2 is quite complex and the only
authoritative information comes from the source code itself. A brief &
incomplete design doc is here.

https://sourceforge.net/p/iperf2/code/ci/master/tree/doc/DESIGN_NOTES

Bob

On Mon, Jan 10, 2022, 4:31 AM Zvi Vered  wrote:

> Hello,
>
> I have to write a TCP server application that should respond to iperf in
> client mode running under windows.
>
> The server side runs with lwip under TI's TIVA.
>
> Can you please provide the ICD that I should handle in the server side ?
>
> Thank you,
> Zvika
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf and video streaming

[Bob McMahon via Iperf-users]

There are some slides on the sourceforge site

https://sourceforge.net/projects/iperf2/files/Iperf%202.0.13%20Enhancements.pdf/download
https://sourceforge.net/projects/iperf2/files/Iperf%202.0.14%20New%20Features.pdf/download

Bob

On Mon, Oct 25, 2021 at 3:00 AM karima smida  wrote:

> Hi all,
> Please, can you provide a tutorial on how to use iperf to measure
> throughput of video streaming  and web browsing applications.
> Thank you in advance.
>
> --
> Karima SMIDA
> PhD Student
> Mediatron
> *SupCom*
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf can support QUIC

[Bob McMahon via Iperf-users]

Testing QUIC is of interest to iperf 2 community. It would be good to gauge
interests as well as understand any other options to test QUIC. I would
like to verify that iperf is the best tool for this.  Comments around that
would be helpful.

Bob

On Mon, Oct 4, 2021 at 9:54 AM HARISH KUMAR Ivaturi <
harishkumarivat...@gmail.com> wrote:

> Hi
>
> Based on this iperf draft document which has been released recently on how
> to calculate throughput of QUIC (in a pure networking side) Framework for
> QUIC Throughput Testing (ietf.org)
> 
>
> I believe there is a possible way to introduce quic flag and run it for
> bidirectional traffic for server and client in order to get more throughput
> value.
>
> Can Iperf developers make this open source and release a solution on this?
>
> Thanks
>
> BR
> Harish Kumar
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3 - Server timout?

[Bob McMahon via Iperf-users]

I can't speak for iperf 3 but iperf 2
supports -t on the server side.
Though I'm not sure if this is what you're wanting as -t will kill the
server/listener process and you'll still need to restart it.

Bob

On Mon, Jul 5, 2021 at 9:02 AM Neil Yeoman 
wrote:

> Hi,
>
>
>
> I am running Iperf3 (3.7) on a PC (Linux Mint) as the server, with the
> client on a development board (Linux). The client connects via LTE (4G),
> running a 5 second test every 30 seconds. I am Logging GPS location against
> the cellular parameters and the reported Iperf3 throughput measurements.
>
>
>
> The problem I am seeing is that if the cellular service is lost during the
> test period, the test finishes on the client (–t 5) as expected, but the
> following test 30s later cannot re-establish to the server as it still has
> the port in use. If we restart the server then all is back to normal.
>
>
>
> I am trying to find a timeout command for the server side but it doesn’t
> appear to be implemented, can anyone suggest how this problem can be
> resolved. I hope I am missing something obvious.
>
>
>
> TIA
>
>
>
> Neil.
>
>
>
>
>
> P Before printing, please think about the Environment.
>
> This email message and any accompanying attachments may contain
> information which is confidential. If you are not the intended recipient
> then you must not read, use, disseminate, distribute or copy this message
> or attachments. If you have received this message in error then please
> notify the sender immediately and delete this message. Any views expressed
> in this message are those of the individual sender except where the sender
> expressly, and with authority, expresses them to be the view of Team
> Telecom Group Ltd. Before opening any attachments, please check them for
> viruses and defects.
>
> Team Telecom Group Ltd, Field House, Derby, DE1 1NH
>
> This message has been scanned for viruses & other malicious content
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf speed test results

[Bob McMahon via Iperf-users]

What version of iperf are you running? What protocol, TCP or UDP? Not sure
what you mean by "iperf managing testing"

With iperf 2, more streams will cause more traffic threads and use more CPU
cores and get higher throughput when a single core can't saturate a link.
Try -u -l 18 to see that CPU as a the bottleneck.

Iperf 2 separates accounting from traffic per  a separate reporting and
accounting thread so there is relatively no cost to "perform traffic
accounting" assuming multiple cores.

Bob

On Fri, Jun 25, 2021 at 12:42 AM Luis Hurtado Llopis <
hurtadollopis.l...@gmail.com> wrote:

>
> Hi,
>
> Would like to ask you something which make me doubt regarding Iperf speed
> test results.
>
> When I test it by using 10/20 or more streams I get higher speed rates
> than when I test it with only one stream. For me this is a little bit
> strange because I think with one stream sending data it is less packet load
> than 20 streams, then it should be faster to manage that load having higher
> data rates.
>
> So, is this result related with the way Iperf manage the testing?
>
> Many thanks in advance,
> Luis
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Non-terminating thread when performing download measurement

[Bob McMahon via Iperf-users]

hmm, this looks like a bug. Do you want to file a ticket on it? One can do
that here.

https://sourceforge.net/p/iperf2/tickets/

Bob

PS. I'm way behind in sending out shirts to iperf 2 volunteers. I need to
figure out a system to collect mail to addresses and size that's secure and
private.

On Fri, Jun 18, 2021 at 10:41 AM Gustavo Silva 
wrote:

> Hi,
> I'm running iperf-2.1.1-dev on an OpenWRT system using the following
> command:
>
> iperf --client "server-url" -p 5001 --format m --time 10 --reverse
>
> The measurement is successful but there seems to be a thread that is never
> joined, therefore making the process run endlessly. I cross-compiled iperf
> from source for my target using debugging flags such as
> --enable-thread-debug and the resulting log can be seen in the attached
> file iperflog-openwrt.txt.
>
> For comparison, I also runned the same measurement on my PC (Ubuntu 20.04)
> and the process terminated correctly. See the attached file
> iperflog-ubuntu.txt.
> The difference can be seen in the last few lines of the log files. While
> on Ubuntu the reporter thread finishes correctly:
>
> THREAD(45773):[16:52:03.100912] Free common=0x7f5e84000d50
> THREAD(45773):[16:52:03.100965] reporter thread job queue request lock
> THREAD(45773):[16:52:03.101013] reporter thread job queue unlock
> THREAD(45773):[16:52:03.101059] Reporter thread finished user/traffic 1/0
> THREAD(45773):[16:52:03.101139] Free thread settings=0x55d046cda8d0
>
> On OpenWRT it doesn't:
>
> THREAD(17129):[19:33:26.868959] Free common=0x77de58e0
> THREAD(17129):[19:33:26.869685] Server destructor sock=3 fullduplex=false
> THREAD(17129):[19:33:26.870928] Free thread settings=0x77f3f730
> THREAD(17127):[19:33:27.864247] Jobq *WAIT* exit  0/0 cond=0x447ac4
> threads=1
> THREAD(17127):[19:33:28.864703] Jobq *WAIT* exit  0/0 cond=0x447ac4
> threads=1
> THREAD(17127):[19:33:29.865145] Jobq *WAIT* exit  0/0 cond=0x447ac4
> threads=1
> THREAD(17127):[19:33:30.865592] Jobq *WAIT* exit  0/0 cond=0x447ac4
> threads=1
>
> Some additional information:
> OS: OpenWRT 19.07.7
> Processor architecture: MIPS 32
>
> Thank you in advance!
>
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf-3.10 is available

[Bob McMahon via Iperf-users]

Hi Bruce,

We used the *%* for both tx and and rx device binding in iperf 2. Just
something to consider for consistency between the two tools.

*To affect the physical output interface (e.g. dual homed systems) either
use -c % (requires root) which bypasses this host route table
lookup, or configure policy routing per each -B source address and set the
output interface appropriately in the policy routes. On the server or
receive, only packets destined to -B IP address will be received. It's also
useful for multicast. For example, iperf -s -B 224.0.0.1%eth0 will only
accept ip multicast packets with dest ip 224.0.0.1 that are received on the
eth0 interface, while iperf -s -B 224.0.0.1 will receive those packets on
any interface, Finally, the device specifier is required for v6 link-local,
e.g. -c [v6addr]% -V, to select the output interface.*

Bob

On Tue, Jun 1, 2021 at 11:07 AM Bruce A. Mah  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> ESnet (Energy Sciences Network) is proud to announce the availability
> of iperf 3.10.  This release is primarily a bugfix release. A few new
> features, controlled by various new command-line flags, have been
> added (--time-skew-threshold, --bind-dev, --rcv-timeout,
> - --dont-fragment). More information can be found in the iperf-3.10
> release notes, which are contained in the RELNOTES.md file in the
> distribution.
>
> iperf 3.10 should be fully backward-compatible with prior iperf3
> releases, that is, iperf 3.10 clients and servers should interoperate
> correctly with all 3.x clients and servers.
>
> iperf3 is a tool for measuring the maximum TCP, UDP, and SCTP
> throughput along a path, allowing for the tuning of various parameters
> and reporting measurements such as throughput, jitter, and datagram
> packet loss.  It is fully supported on Linux, FreeBSD, and macOS.  It
> may run on other platforms as well, although it has not received the
> same attention and testing.  Note that iperf3 is not compatible with,
> and will not interoperate with, version 2 or earlier of iperf,
> although the two versions can co-exist on the same hosts and networks.
>
> The source code for iperf 3.10 is available at:
>
> https://downloads.es.net/pub/iperf/iperf-3.10.tar.gz
>
> SHA256 hash:
>
> 4390982928542256c17d6dd1f56eede9092649ebfd8a97c8cecfad12d238ad57
>
> 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:
>
> https://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
>
> User questions can go to the iperf users list (which is more-or-less
> shared between iperf2 and iperf3):
>
> iperf-users@lists.sourceforge.net
>
> Mailing list information and archives can be found at:
>
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
> The mailing list for iperf3 development is:
>
> iperf-...@googlegroups.com
>
> To see the list archives or join the mailing list, visit:
>
> http://groups.google.com/group/iperf-dev
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmCu5NQACgkQSYSRCoyq
> 7opv6wf9FtXz7HtWz4er0Tyre3maBj3mvn2/NYFAKsZnhdLZW4EOVU9JD7XSrrX7
> lKPqQV2FM0PS412ttJgnn6Hoby0lVvUqOsNBxN3BtefxUSpQyWrmG0a0b12vz10Q
> dgJ0q2XYtmFgVEi2+9kzuPdPeAw/IwJ1pg0RZNIWupKqhflPdFJw8nDls/eeN26h
> abf5XpLsNIDLAJi58mwsTr+94t34RkYaWj/MDT5fjYru9LjXcEHMh00JnD2RAwyg
> OOQT5qIXyQIaFK1akxu2lOwlKgZp401LFVnYyyP9LMDhTlmCqLbnWwB1mNiOk1jH
> tCnjDwITiBRCVRN2E6/kzNtrj//KpQ==
> =CZRC
> -END PGP SIGNATURE-
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>

-- 
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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] (no subject)

[Bob McMahon via Iperf-users]

Hi All,

Please offer feedback per the following and please forward to relevant and
interested parties.

*Problem statement: *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 man page
.
*--burst-period[=**n**]*Set the burst period in seconds. Defaults to one
second. (Note: assumed use case is low duty cycle traffic bursts)
*--burst-size[=**n**]*Set the burst size in bytes. Defaults to 1M if no
value is given.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.

These settings will work for both UDP and TCP traffic (though UDP is yet to
be coded up.)


*Proposed server side output:*

[rjmcmahon@localhost iperf2-code]$ iperf -s -e

Server listening on TCP port 5001 with pid 28094
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP window size:  128 KByte (default)

[  1] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.113 port
59646 (MSS=1448) (*burst-period=2.00*) (trip-times) (sock=4) (peer
2.1.1-dev) on 2021-03-18 17:56:25 (PDT)
[ ID] Burst (start-end)  Transfer Bandwidth   *XferTime*  *(DC%) *
  Reads=Dist  NetPwr
[  1] *0.-0.0092 sec  1.00 MBytes   911 Mbits/sec   9.214 ms (0.46%)*
 572=571:0:0:1:0:0:0:0  12
[  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
[  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
[  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
[  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
[  1] 0.-10.0022 sec  5.13 MBytes  4.30 Mbits/sec
2341=2334:5:1:1:0:0:0:0


*where XferTime *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.)

and *DC is a Duty Cycle* calculation, i.e. XferTime/burst-period. Also note
the Bandwidth calculation is computed per the xfer time,
i.e. packet or read/write events, and doesn't use as sample interval like
-i does.


*Client side command for the above:*


[rjmcmahon@ryzen3950 iperf2-code]$ src/iperf -c 192.168.1.10
*--burst-period=2.0 * --trip-times

Client connecting to 192.168.1.10, TCP port 5001 with pid 29040 (1 flows)
Write buffer size: 131072 Byte
Bursting: 1.00 MByte every 2.00 seconds
TCP window size: 85.0 KByte (default)

[  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)
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
Cwnd/RTTNetPwr
[  1] 0.-10.0107 sec  5.13 MBytes  4.29 Mbits/sec  43/0  0
 127K/1590 us  338
[rjmcmahon@ryzen3950 iperf2-code]$


*Background:*

Most iperf based testing has been high duty cycle or congested traffic.
This allows one to measure things like peak average throughput.

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.

The transmits are scheduled per clock_nanosleep
 and done are a per traffic
thread basis. (Things like -P will be supported.)

There are major differences in the server side output (client side output
is TBD) per:

   1. The timestamps are now burst based, start of burst to end of burst
   2. The burst size is displayed
   3. Bandwidth calculation is based on start of burst to end of burst and
   the burst size
   4. The burst transfer time is provided in units of milliseconds and
   resolution of microseconds
   5. A duty cycle output in percentage is provided as a convenience

Note: applying the duty cycle to any specific resource is out of context of
this proposal.  Basically, time is the resource used here.

Here is another run like above where the burst side is set to 10MBytes,
notice the change in the output

[rjmcmahon@localhost iperf2-code]$ iperf -s -e

Server listening on TCP port 5001 with pid 28516
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP window size:  128 KByte (default)

[  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 

[Iperf-users] iperf 2.0.14 experimental feature --near-congestion

[Bob McMahon via Iperf-users]

Hi All,

I've added an experimental feature to iperf 2.0.14
 per
option --near-congestion=. This is useful when measuring TCP write
to read latencies at high throughput but not at bufferbloat. It requires a
very much controlled network to be repeatable and, even then, still
requires some knob tuning.

*The idea is to rate limit the tcp writes by sampling the RTT after each
write buffer per -l completes.* The delay is weighted per a multiplier of
the RTT. This allows the queues to drain.  The RTT multiplier can be any
value zero or greater. It's loosely based off this paper

.

This feature is committed in version starting Dec 22

[rjmcmahon@localhost iperf2-code]$ iperf -v
iperf version 2.0.14a (22 Dec 2020) pthreads

Here's an example testing against a raspberry pi 4 wired gigE.

*First with the delay being 0.4 of the RTT sampled after the -l write size.*
Throughput is fairly high and the write to read latency averages 3.5 ms.

[rjmcmahon@localhost Code]$ iperf -c 192.168.1.108 -i 1 --trip-times
 --near-congestion=0.4 -e

Client connecting to 192.168.1.108, TCP port 5001 with pid 11219 (1 flows)
Write buffer size: 131072 Byte
TCP near-congestion delay weight set to 0.4000
TCP window size: 85.0 KByte (default)

[  1] local 192.168.1.62%enp2s0 port 48100 connected with 192.168.1.108
port 5001 (MSS=1448) (trip-times) (sock=3) (ct=0.28 ms) on 2020-12-22
22:32:39 (PST)
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
Cwnd/RTTNetPwr
[  1] 0.00-1.00 sec   112 MBytes   943 Mbits/sec  900/0  0
 567K/2566 us  45921
[  1] 1.00-2.00 sec   112 MBytes   941 Mbits/sec  897/0  0
 567K/1653 us  71126
[  1] 2.00-3.00 sec   111 MBytes   931 Mbits/sec  888/0  0
 695K/2418 us  48136
[  1] 3.00-4.00 sec   111 MBytes   932 Mbits/sec  889/0  0
 695K/1407 us  82817
[  1] 4.00-5.00 sec   109 MBytes   913 Mbits/sec  871/0  0
 695K/2062 us  55366
[  1] 5.00-6.00 sec   112 MBytes   935 Mbits/sec  892/0  0
 695K/2484 us  47068
[  1] 6.00-7.00 sec   112 MBytes   938 Mbits/sec  895/0  0
 695K/2511 us  46718
[  1] 7.00-8.00 sec   112 MBytes   938 Mbits/sec  895/0  0
 695K/1895 us  61905
[  1] 8.00-9.00 sec   111 MBytes   929 Mbits/sec  886/0  0
 695K/2495 us  46545
[  1] 9.00-10.00 sec   112 MBytes   940 Mbits/sec  896/0  0
 695K/3403 us  34511
[  1] 0.00-10.00 sec  1.09 GBytes   934 Mbits/sec  8912/0  0
 695K/3403 us  34322

root@rpi4-rjm-1:/usr/local/src/iperf2-code# src/iperf -s -i 1 -e

Server listening on TCP port 5001 with pid 3805
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP window size:  128 KByte (default)

[  1] local 192.168.1.108%eth0 port 5001 connected with 192.168.1.62 port
48100 (MSS=453) (trip-times) (sock=4) (peer 2.0.14-alpha) on 2020-12-22
22:32:39 (PST)
[ ID] IntervalTransferBandwidthBurst Latency
avg/min/max/stdev (cnt/size) inP NetPwr  Reads=Dist
[  1] 0.00-1.00 sec   112 MBytes   940 Mbits/sec  3.668/2.166/12.241/1.761
ms (896/131130)  423 KByte 32032  46203=46139:39:7:7:4:2:0:5
[  1] 1.00-2.00 sec   112 MBytes   939 Mbits/sec  3.172/2.295/5.212/0.158
ms (896/131013)  364 KByte 37009  38631=38511:93:3:0:1:0:0:23
[  1] 2.00-3.00 sec   111 MBytes   932 Mbits/sec  3.447/1.205/6.307/0.997
ms (889/131103)  391 KByte 33815  31142=30806:18:0:0:0:0:0:318
[  1] 3.00-4.00 sec   111 MBytes   932 Mbits/sec  4.485/1.247/10.803/2.049
ms (889/131040)  512 KByte 25972  24613=24166:4:2:0:0:1:0:440
[  1] 4.00-5.00 sec   109 MBytes   913 Mbits/sec  3.866/1.248/6.951/1.442
ms (871/131072)  431 KByte 29529  871=0:0:0:0:0:0:0:871
[  1] 5.00-6.00 sec   112 MBytes   936 Mbits/sec  3.295/1.249/5.933/0.750
ms (892/131192)  376 KByte 35514  37172=36953:6:4:1:0:0:1:207
[  1] 6.00-7.00 sec   112 MBytes   938 Mbits/sec  3.537/1.252/9.147/1.041
ms (895/131019)  405 KByte 33153  39414=39229:14:3:1:0:0:0:167
[  1] 7.00-8.00 sec   112 MBytes   936 Mbits/sec  3.467/1.224/7.949/0.904
ms (893/131004)  396 KByte 33742  38755=38566:10:2:0:0:0:0:177
[  1] 8.00-9.00 sec   111 MBytes   932 Mbits/sec  3.510/1.212/6.808/1.064
ms (888/131132)  399 KByte 33173  27034=26636:2:2:1:0:0:0:393
[  1] 9.00-10.00 sec   112 MBytes   937 Mbits/sec  3.308/2.732/7.023/0.600
ms (894/131012)  379 KByte 35406  43303=43197:15:4:0:0:0:0:87
[  1] 0.00-10.00 sec  1.09 GBytes   934 Mbits/sec  3.576/1.205/12.241/1.249
ms (8909/131072)  408 KByte 32644  327144=324203:201:27:10:5:3:1:2694

*Next, the delay is 0 so TCP drives to bufferbloat. Network power is 8512
vs 34322 and the 

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

Go here

https://sourceforge.net/projects/iperf/lists/iperf-users/unsubscribe

Bob

On Fri, Dec 4, 2020 at 2:24 AM shaukath ali via Iperf-users <
iperf-users@lists.sourceforge.net> wrote:

> Hi Mates, How to unsubscribe from this alias. Regds, Shaukath.
>
> From: Bob McMahon via Iperf-users 
> Sent: Thu, 03 Dec 2020 23:05:27
> To: Tim Chown 
> Cc: iPerf User Group 
> Subject: Re: [Iperf-users] Feature - Throughput ramp up
>
> Sorry for being off topic but curious about perfSonar's ability to sync
> the clocks to the GPS atomic clocks. We found this really helps with iperf
> 2.0.14 latency features (see the client side --trip-times option.
> <https://iperf2.sourceforge.io/iperf-manpage.html=UHZTOVUzAnJSdlVgV3dTMFM4>)
>
>
> We've also found that, while RTT is of interest to network stack
> engineers, it's the end/end delay that impacts user experience.  That's why
> we've added write-start to read-finished latencies supporting both
> parametric and non-parametric distributions (i.e. mean/min/max/stdev and
> histograms.). Similar for video frame latencies, first packet of frame
> start to final packet of frame read.
>
> It seems good for tooling to include direct latency measurements as
> standard practice. Ping is a suboptimal technique for multiple reasons
> though it doesn't require clock sync.
>
> Bob
>
> On Thu, Dec 3, 2020 at 4:00 AM Tim Chown  wrote:
>
>> Hi,
>>
>> This is something you could do relatively easily I think if you ran
>> perfSONAR measurement points at the systems of interest and then pSConfig
>> or pScheduler to configure the tests.  Results would then be archived and
>> available for historical analysis.
>>
>> Tim
>>
>> > On 1 Dec 2020, at 23:52, Bob McMahon via Iperf-users <
>> iperf-users@lists.sourceforge.net> wrote:
>> >
>> > Ok, after some further discussions we've concluded this feature is best
>> implemented by a script and not within iperf itself. The primary reason
>> being is that an iperf client and iperf server don't have a feedback system
>> per the "iperf protocol," i.e. stats on the server are not fed back to the
>> client where traffic offered load decisions really need to know them to be
>> effective. Note: Iperf does support traffic patterns that don't require
>> source and sink knowledge, e.g. a video stream is defined by the source not
>> the receiver, so that's supported.
>> >
>> > A python script using flows can better achieve this class of problems
>> because it has complete flow information in near real time. It also scales
>> well.  The down side is a python script needs to be written. The hard part
>> is mostly done with the flows and openssh modules.
>> >
>> > Bob
>> >
>> > On Tue, Dec 1, 2020 at 1:18 PM Bob McMahon 
>> wrote:
>> > The flows code is likely broken at the moment.  I've been focussed on
>> iperf 2.0.14 itself.
>> >
>> > The basic requirement is ssh access to both ends used to create a flow
>> via a python interpreter running 3.5 or greater (per the use of python's
>> asyncio.)  The iperf hosts don't need to run python just ssh pipes and have
>> a local iperf binary.
>> >
>> > Async or event based programming is a bit more challenging than
>> procedural based so keep that in mind.  Simple traffic is easy as it's just
>> installations of flows then flow commence and flow cease which are class
>> methods. (Note: flows is in the experimental state too.)
>> >
>> > The data is put into a dictionary.  The outputs are basically a csv
>> file but that's a pain. So one would probably want to integrate output
>> logic into a python script itself that imports the flows and ssh modules.
>> There is an example with computing a Kolmogorov smirnov table which is used
>> to cluster lots of latency distributions. These distributions can be
>> non-parametric so the KS distance is a good choice for a distance matrix -
>> though not the only one. We'll run thousands of tests and want to cluster
>> results.
>> >
>> > Bob
>> >
>> > On Tue, Dec 1, 2020 at 12:58 PM Craig Reeves 
>> wrote:
>> > Bob,
>> >
>> > I am good with write side only since we can flip the ends (we normally
>> have access to both ends we are using for testing).
>> >
>> > I am a python newbie, but I will take your advice and look at it.  I
>> was not aware of the pyflows module.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Craig Reeves
>> >
>> > "Bridging Communicatio

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

sure thing.  We do a lot of sweeps so this seemed a natural thing to
consider.  It's just better done by a script for this type of request.

We've considered hooking up a feedback path (similar to ful-duplex mode)
were the server stats are fed back to the client in "real-time."  It's a
fair amount of work to do this and difficult over lossy UDP. Aslo, what
exactly to do with the feedback stats can't be easily generalized.

For a feature of this type, we'd probably prototype using python code first
and prove a use case before committing it to C or C++.

Having ssh pipes to both iperf sessions really makes things a lot easier.
Python's asyncio has proven itself to be quite good.

Bob

On Tue, Dec 1, 2020 at 4:55 PM Craig Reeves 
wrote:

> Bob,
>
> I appreciate you giving it some consideration.
>
> On Tue, Dec 1, 2020, 5:52 PM Bob McMahon  wrote:
>
>> Ok, after some further discussions we've concluded this feature is best
>> implemented by a script and not within iperf itself. The primary reason
>> being is that an iperf client and iperf server don't have a feedback system
>> per the "iperf protocol," i.e. stats on the server are not fed back to the
>> client where traffic offered load decisions really need to know them to be
>> effective. Note: Iperf does support traffic patterns that don't require
>> source and sink knowledge, e.g. a video stream is defined by the source not
>> the receiver, so that's supported.
>>
>> A python script using flows can better achieve this class of problems
>> because it has complete flow information in near real time. It also scales
>> well.  The down side is a python script needs to be written. The hard part
>> is mostly done with the flows and openssh modules.
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 1:18 PM Bob McMahon 
>> wrote:
>>
>>> The flows code is likely broken at the moment.  I've been focussed on
>>> iperf 2.0.14 itself.
>>>
>>> The basic requirement is ssh access to both ends used to create a flow
>>> via a python interpreter running 3.5 or greater (per the use of python's
>>> asyncio <https://docs.python.org/3/library/asyncio.html>.)  The iperf
>>> hosts don't need to run python just ssh pipes and have a local iperf
>>> binary.
>>>
>>> Async or event based programming
>>> <https://en.wikipedia.org/wiki/Event-driven_programming> is a bit more
>>> challenging than procedural based so keep that in mind.  Simple traffic is
>>> easy as it's just installations of flows then flow commence and flow
>>> cease
>>> <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py> which
>>> are class methods. (Note: flows is in the experimental state too.)
>>>
>>> The data is put into a dictionary.  The outputs are basically a csv file
>>> but that's a pain. So one would probably want to integrate output logic
>>> into a python script itself that imports the flows and ssh modules.  There
>>> is an example with computing a Kolmogorov smirnov table which is used to
>>> cluster lots of latency distributions. These distributions can be
>>> non-parametric so the KS distance is a good choice for a distance matrix -
>>> though not the only one. We'll run thousands of tests and want to cluster
>>> results.
>>>
>>> Bob
>>>
>>> On Tue, Dec 1, 2020 at 12:58 PM Craig Reeves 
>>> wrote:
>>>
>>>> Bob,
>>>>
>>>> I am good with write side only since we can flip the ends (we normally
>>>> have access to both ends we are using for testing).
>>>>
>>>> I am a python newbie, but I will take your advice and look at it.  I
>>>> was not aware of the pyflows module.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Craig Reeves
>>>>
>>>> "Bridging Communications"
>>>> 3520 Lorna Ridge Drive
>>>> Hoover, AL 35216
>>>> v.(205) 829-1800
>>>> f. (205) 536-6333
>>>> c. (205) 332-5916
>>>>
>>>>
>>>> On Tue, Dec 1, 2020 at 2:54 PM Bob McMahon 
>>>> wrote:
>>>>
>>>>> This doesn't seem to require read side rate limiting.  I think write
>>>>> side would do it.  The full-duplex may be useful too. Then debug options
>>>>> are like:
>>>>>
>>>>>- iperf -c  --full-duplex -u
>>>>>--sweep-range=1m,10m,1m --sweep-step 10 -i 1 -l 200 -S 0xc0
>>>>>- iperf -c  --revers

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

Ok, after some further discussions we've concluded this feature is best
implemented by a script and not within iperf itself. The primary reason
being is that an iperf client and iperf server don't have a feedback system
per the "iperf protocol," i.e. stats on the server are not fed back to the
client where traffic offered load decisions really need to know them to be
effective. Note: Iperf does support traffic patterns that don't require
source and sink knowledge, e.g. a video stream is defined by the source not
the receiver, so that's supported.

A python script using flows can better achieve this class of problems
because it has complete flow information in near real time. It also scales
well.  The down side is a python script needs to be written. The hard part
is mostly done with the flows and openssh modules.

Bob

On Tue, Dec 1, 2020 at 1:18 PM Bob McMahon  wrote:

> The flows code is likely broken at the moment.  I've been focussed on
> iperf 2.0.14 itself.
>
> The basic requirement is ssh access to both ends used to create a flow via
> a python interpreter running 3.5 or greater (per the use of python's
> asyncio <https://docs.python.org/3/library/asyncio.html>.)  The iperf
> hosts don't need to run python just ssh pipes and have a local iperf
> binary.
>
> Async or event based programming
> <https://en.wikipedia.org/wiki/Event-driven_programming> is a bit more
> challenging than procedural based so keep that in mind.  Simple traffic is
> easy as it's just installations of flows then flow commence and flow cease
> <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py> which
> are class methods. (Note: flows is in the experimental state too.)
>
> The data is put into a dictionary.  The outputs are basically a csv file
> but that's a pain. So one would probably want to integrate output logic
> into a python script itself that imports the flows and ssh modules.  There
> is an example with computing a Kolmogorov smirnov table which is used to
> cluster lots of latency distributions. These distributions can be
> non-parametric so the KS distance is a good choice for a distance matrix -
> though not the only one. We'll run thousands of tests and want to cluster
> results.
>
> Bob
>
> On Tue, Dec 1, 2020 at 12:58 PM Craig Reeves 
> wrote:
>
>> Bob,
>>
>> I am good with write side only since we can flip the ends (we normally
>> have access to both ends we are using for testing).
>>
>> I am a python newbie, but I will take your advice and look at it.  I was
>> not aware of the pyflows module.
>>
>>
>>
>> Thanks,
>>
>> Craig Reeves
>>
>> "Bridging Communications"
>> 3520 Lorna Ridge Drive
>> Hoover, AL 35216
>> v.(205) 829-1800
>> f. (205) 536-6333
>> c. (205) 332-5916
>>
>>
>> On Tue, Dec 1, 2020 at 2:54 PM Bob McMahon 
>> wrote:
>>
>>> This doesn't seem to require read side rate limiting.  I think write
>>> side would do it.  The full-duplex may be useful too. Then debug options
>>> are like:
>>>
>>>- iperf -c  --full-duplex -u --sweep-range=1m,10m,1m
>>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>>- iperf -c  --reverse -u --sweep-range=1m,10m,1m
>>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>>- iperf -c  --u --sweep-range=1m,10m,1m --sweep-step
>>>10 -i 1 -l 200 -S 0xc0
>>>
>>> which should cover the to/fro directions as well as full duplex (as well
>>> as set the access class to VOIP priority.)
>>>
>>> If you can get clock sync then --trip-times might be useful too.  Man
>>> page here <https://iperf2.sourceforge.io/iperf-manpage.html>
>>>
>>> I'd suggest writing a python script using pyflows
>>> <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/> if you
>>> need the full duplex case to be synchronized before each step or for
>>> triangulated flows (iperf 2.0.14 does support --incr-dstip with -P but I
>>> doubt this will work for your triangulation needs.)  Using a python script,
>>> one can then just use iperf and add the new features via python code.
>>>
>>> Note: Adding step sync over UDP with iperf isn't trivial - too much
>>> handshaking required. It may require a control socket similar to iperf 3.
>>> We've purposely tried to avoid a TCP socket for UDP tests in iperf 2 so
>>> it's not something we'd want to do.
>>>
>>> The question becomes, should this all be a python script using flows or
>>> is there enough value add in having iperf do it itself with the knowledge
>>> there won't be any step sy

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

The flows code is likely broken at the moment.  I've been focussed on iperf
2.0.14 itself.

The basic requirement is ssh access to both ends used to create a flow via
a python interpreter running 3.5 or greater (per the use of python's asyncio
<https://docs.python.org/3/library/asyncio.html>.)  The iperf hosts don't
need to run python just ssh pipes and have a local iperf binary.

Async or event based programming
<https://en.wikipedia.org/wiki/Event-driven_programming> is a bit more
challenging than procedural based so keep that in mind.  Simple traffic is
easy as it's just installations of flows then flow commence and flow cease
<https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py> which
are class methods. (Note: flows is in the experimental state too.)

The data is put into a dictionary.  The outputs are basically a csv file
but that's a pain. So one would probably want to integrate output logic
into a python script itself that imports the flows and ssh modules.  There
is an example with computing a Kolmogorov smirnov table which is used to
cluster lots of latency distributions. These distributions can be
non-parametric so the KS distance is a good choice for a distance matrix -
though not the only one. We'll run thousands of tests and want to cluster
results.

Bob

On Tue, Dec 1, 2020 at 12:58 PM Craig Reeves 
wrote:

> Bob,
>
> I am good with write side only since we can flip the ends (we normally
> have access to both ends we are using for testing).
>
> I am a python newbie, but I will take your advice and look at it.  I was
> not aware of the pyflows module.
>
>
>
> Thanks,
>
> Craig Reeves
>
> "Bridging Communications"
> 3520 Lorna Ridge Drive
> Hoover, AL 35216
> v.(205) 829-1800
> f. (205) 536-6333
> c. (205) 332-5916
>
>
> On Tue, Dec 1, 2020 at 2:54 PM Bob McMahon 
> wrote:
>
>> This doesn't seem to require read side rate limiting.  I think write side
>> would do it.  The full-duplex may be useful too. Then debug options are
>> like:
>>
>>- iperf -c  --full-duplex -u --sweep-range=1m,10m,1m
>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>- iperf -c  --reverse -u --sweep-range=1m,10m,1m
>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>- iperf -c  --u --sweep-range=1m,10m,1m --sweep-step
>>10 -i 1 -l 200 -S 0xc0
>>
>> which should cover the to/fro directions as well as full duplex (as well
>> as set the access class to VOIP priority.)
>>
>> If you can get clock sync then --trip-times might be useful too.  Man
>> page here <https://iperf2.sourceforge.io/iperf-manpage.html>
>>
>> I'd suggest writing a python script using pyflows
>> <https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/> if you
>> need the full duplex case to be synchronized before each step or for
>> triangulated flows (iperf 2.0.14 does support --incr-dstip with -P but I
>> doubt this will work for your triangulation needs.)  Using a python script,
>> one can then just use iperf and add the new features via python code.
>>
>> Note: Adding step sync over UDP with iperf isn't trivial - too much
>> handshaking required. It may require a control socket similar to iperf 3.
>> We've purposely tried to avoid a TCP socket for UDP tests in iperf 2 so
>> it's not something we'd want to do.
>>
>> The question becomes, should this all be a python script using flows or
>> is there enough value add in having iperf do it itself with the knowledge
>> there won't be any step synchronization? I see value to the sweep and step
>> when hunting near congestion vs congestion (buffer bloat) so I'll probably
>> add that to iperf itself.
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 12:25 PM Craig Reeves 
>> wrote:
>>
>>> Bob,
>>>
>>> Good question.  So here is a typical scenario.  We have a VOIP server
>>> sitting inside of a customer's data center behind a firewall (e.g.
>>> Sonicwall, PfSense, Palo Alto, etc.).  The phone server is sitting on a
>>> VLAN inside the customer's network and has a 1Gb NIC.  The customer (most
>>> of ours are very large) has a 200Mb Internet pipe from an ISP.  Depending
>>> on the concurrent call volume we ask the customer to do traffic shaping and
>>> guarantee us 10Mb of the 200Mb pipe.  They call after working fine for 2
>>> years and complain that they can't hear outside callers (UDP traffic from
>>> the carrier into the VOIP server is being disrupted).  We will run iperf
>>> tests from an external location (like on our VM setup at our office, or a
>>> VM we have on AWS) and start shooting UDP packets in (usually starting at
>>

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

This doesn't seem to require read side rate limiting.  I think write side
would do it.  The full-duplex may be useful too. Then debug options are
like:

   - iperf -c  --full-duplex -u --sweep-range=1m,10m,1m
   --sweep-step 10 -i 1 -l 200 -S 0xc0
   - iperf -c  --reverse -u --sweep-range=1m,10m,1m
   --sweep-step 10 -i 1 -l 200 -S 0xc0
   - iperf -c  --u --sweep-range=1m,10m,1m --sweep-step 10
   -i 1 -l 200 -S 0xc0

which should cover the to/fro directions as well as full duplex (as well as
set the access class to VOIP priority.)

If you can get clock sync then --trip-times might be useful too.  Man page
here <https://iperf2.sourceforge.io/iperf-manpage.html>

I'd suggest writing a python script using pyflows
<https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/> if you need
the full duplex case to be synchronized before each step or for
triangulated flows (iperf 2.0.14 does support --incr-dstip with -P but I
doubt this will work for your triangulation needs.)  Using a python script,
one can then just use iperf and add the new features via python code.

Note: Adding step sync over UDP with iperf isn't trivial - too much
handshaking required. It may require a control socket similar to iperf 3.
We've purposely tried to avoid a TCP socket for UDP tests in iperf 2 so
it's not something we'd want to do.

The question becomes, should this all be a python script using flows or is
there enough value add in having iperf do it itself with the knowledge
there won't be any step synchronization? I see value to the sweep and step
when hunting near congestion vs congestion (buffer bloat) so I'll probably
add that to iperf itself.

Bob

On Tue, Dec 1, 2020 at 12:25 PM Craig Reeves 
wrote:

> Bob,
>
> Good question.  So here is a typical scenario.  We have a VOIP server
> sitting inside of a customer's data center behind a firewall (e.g.
> Sonicwall, PfSense, Palo Alto, etc.).  The phone server is sitting on a
> VLAN inside the customer's network and has a 1Gb NIC.  The customer (most
> of ours are very large) has a 200Mb Internet pipe from an ISP.  Depending
> on the concurrent call volume we ask the customer to do traffic shaping and
> guarantee us 10Mb of the 200Mb pipe.  They call after working fine for 2
> years and complain that they can't hear outside callers (UDP traffic from
> the carrier into the VOIP server is being disrupted).  We will run iperf
> tests from an external location (like on our VM setup at our office, or a
> VM we have on AWS) and start shooting UDP packets in (usually starting at
> 1Mb with a small datagram and working our way up to the 10Mb limit).  Most
> of the time we start seeing issues with dropped packets at 3Mb/s.  This
> then forces us to look at the Firewall and see if it is overwhelmed doing
> the shaping.  If not then we setup a "triangulation" where we do iperf
> tests with 2 separate external sources and see the times when both pipes
> show dropped packets.  If we see consistent drops from 2 separate legs this
> invariable points to an upstream problem at the ISP.
>
> Hope that helps,
>
> Craig Reeves
>
> "Bridging Communications"
> 3520 Lorna Ridge Drive
> Hoover, AL 35216
> v.(205) 829-1800
> f. (205) 536-6333
> c. (205) 332-5916
>
>
> On Tue, Dec 1, 2020 at 2:08 PM Bob McMahon 
> wrote:
>
>> For UDP, are you expecting the sweep applies both to client and server at
>> the same time?  I guess I'm confused about UDP read size rate limiting. If
>> the client applies 100m and the server is read limited per a sweep there is
>> going to be drops.  UDP doesn't flow control the client.
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 11:42 AM Craig Reeves 
>> wrote:
>>
>>> Yes, but the percentage of drops is fairly low in a clean network pipe.
>>>
>>> Craig Reeves
>>>
>>> "Bridging Communications"
>>> 3520 Lorna Ridge Drive
>>> Hoover, AL 35216
>>> v.(205) 829-1800
>>> f. (205) 536-6333
>>> c. (205) 332-5916
>>>
>>>
>>> On Tue, Dec 1, 2020 at 1:39 PM Bob McMahon 
>>> wrote:
>>>
>>>> Ok, read side limiting would trigger source flow control for TCP and
>>>> cause drops per UDP. Is that what you'd expect?
>>>>
>>>> Bob
>>>>
>>>> On Tue, Dec 1, 2020 at 11:36 AM Craig Reeves 
>>>> wrote:
>>>>
>>>>> Bob,
>>>>>
>>>>> Yes, we would need the Read side as well.  Sometimes we see packets
>>>>> drop from a single direction (that is actually very common).  Technically
>>>>> we could just flip the roles of the 2 ends so it isn't critical.
>>>>>
>>>>> Crai

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

Ok, read side limiting would trigger source flow control for TCP and cause
drops per UDP. Is that what you'd expect?

Bob

On Tue, Dec 1, 2020 at 11:36 AM Craig Reeves 
wrote:

> Bob,
>
> Yes, we would need the Read side as well.  Sometimes we see packets drop
> from a single direction (that is actually very common).  Technically we
> could just flip the roles of the 2 ends so it isn't critical.
>
> Craig Reeves
>
> "Bridging Communications"
> 3520 Lorna Ridge Drive
> Hoover, AL 35216
> v.(205) 829-1800
> f. (205) 536-6333
> c. (205) 332-5916
>
>
> On Tue, Dec 1, 2020 at 1:32 PM Bob McMahon 
> wrote:
>
>> Also, this would only be on the client. Iperf 2.0.14 supports both write
>> and read rate limiting via -b on the server as well as client.  Sweeps
>> wouldn't be supported by the server (or on the read side.)
>>
>> Any issue with that, or, is there a read size need as well?
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 11:29 AM Craig Reeves 
>> wrote:
>>
>>> Bob,
>>>
>>> Thanks, we'd be more than happy to test it out.  Just let me know and
>>> I'll get my engineering group to check it out.
>>>
>>> Craig Reeves
>>>
>>> "Bridging Communications"
>>> 3520 Lorna Ridge Drive
>>> Hoover, AL 35216
>>> v.(205) 829-1800
>>> f. (205) 536-6333
>>> c. (205) 332-5916
>>>
>>>
>>> On Tue, Dec 1, 2020 at 1:21 PM Bob McMahon 
>>> wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> Any reason you need iperf 3 for this and can't use iperf 2.0.14?
>>>>
>>>> We are in the process of early field test for iperf 2.0.14.
>>>> <https://sourceforge.net/projects/iperf2/>  This is probably an
>>>> experimental feature that could be added last minute.  We'd need you to
>>>> test if willing. Our goal is to release 2.0.14 early 2021.
>>>>
>>>> We're out of short options and would need to use long options. Maybe
>>>> something like
>>>>
>>>> --sweep-range=1m,100m, 1m (start, final, step size) defaults to
>>>> 1m,10m,1m with just --sweep-range
>>>> --sweep-steptime 1.5 (units of seconds) defaults to 1 second if
>>>> --sweep-range and no --sweep-steptime
>>>>
>>>> Note that --sweep-range has optional arguments (per the =) and
>>>> sweep-steptime has a mandatory argument (if used.)
>>>>
>>>> All, do comment on more intuitive command line options.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>> Bob
>>>>
>>>> On Tue, Dec 1, 2020 at 8:12 AM Craig Reeves 
>>>> wrote:
>>>>
>>>>> First, many thanks for putting this tool together and sharing it.  It
>>>>> has proved invaluable over the years when dealing with ISPs.
>>>>>
>>>>> That being said, we regularly encounter ISPs that don't think their
>>>>> network has issues.  Most of the time we can pinpoint to a switch or
>>>>> connection that is over saturated.
>>>>>
>>>>> I would love to see a feature that allowed us to set a starting
>>>>> throughput, incremental step up/down throughput, and interval.  This would
>>>>> help find the point at which issues begin.  Here is the idea:
>>>>>
>>>>> iperf3 -c 192.168.1.100 -bt 1M -et 10M -st 10s -t 100 -u
>>>>>
>>>>> -bt = beginning throughput
>>>>> -et = ending throughput
>>>>> -st = step up/down time
>>>>>
>>>>> The thinking is that iperf3 would start a test (UDP or TCP) at 1Mb/s
>>>>> throughput, and then ramp up in 1Mb/s steps ever 10 seconds.
>>>>>
>>>>> This eliminates the need to do individual runs with different settings.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Craig Reeves
>>>>>
>>>>> ___
>>>>> Iperf-users mailing list
>>>>> Iperf-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>>>
>>>>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

For UDP, are you expecting the sweep applies both to client and server at
the same time?  I guess I'm confused about UDP read size rate limiting. If
the client applies 100m and the server is read limited per a sweep there is
going to be drops.  UDP doesn't flow control the client.

Bob

On Tue, Dec 1, 2020 at 11:42 AM Craig Reeves 
wrote:

> Yes, but the percentage of drops is fairly low in a clean network pipe.
>
> Craig Reeves
>
> "Bridging Communications"
> 3520 Lorna Ridge Drive
> Hoover, AL 35216
> v.(205) 829-1800
> f. (205) 536-6333
> c. (205) 332-5916
>
>
> On Tue, Dec 1, 2020 at 1:39 PM Bob McMahon 
> wrote:
>
>> Ok, read side limiting would trigger source flow control for TCP and
>> cause drops per UDP. Is that what you'd expect?
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 11:36 AM Craig Reeves 
>> wrote:
>>
>>> Bob,
>>>
>>> Yes, we would need the Read side as well.  Sometimes we see packets drop
>>> from a single direction (that is actually very common).  Technically we
>>> could just flip the roles of the 2 ends so it isn't critical.
>>>
>>> Craig Reeves
>>>
>>> "Bridging Communications"
>>> 3520 Lorna Ridge Drive
>>> Hoover, AL 35216
>>> v.(205) 829-1800
>>> f. (205) 536-6333
>>> c. (205) 332-5916
>>>
>>>
>>> On Tue, Dec 1, 2020 at 1:32 PM Bob McMahon 
>>> wrote:
>>>
>>>> Also, this would only be on the client. Iperf 2.0.14 supports both
>>>> write and read rate limiting via -b on the server as well as client.
>>>> Sweeps wouldn't be supported by the server (or on the read side.)
>>>>
>>>> Any issue with that, or, is there a read size need as well?
>>>>
>>>> Bob
>>>>
>>>> On Tue, Dec 1, 2020 at 11:29 AM Craig Reeves 
>>>> wrote:
>>>>
>>>>> Bob,
>>>>>
>>>>> Thanks, we'd be more than happy to test it out.  Just let me know and
>>>>> I'll get my engineering group to check it out.
>>>>>
>>>>> Craig Reeves
>>>>>
>>>>> "Bridging Communications"
>>>>> 3520 Lorna Ridge Drive
>>>>> Hoover, AL 35216
>>>>> v.(205) 829-1800
>>>>> f. (205) 536-6333
>>>>> c. (205) 332-5916
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2020 at 1:21 PM Bob McMahon 
>>>>> wrote:
>>>>>
>>>>>> Hi Craig,
>>>>>>
>>>>>> Any reason you need iperf 3 for this and can't use iperf 2.0.14?
>>>>>>
>>>>>> We are in the process of early field test for iperf 2.0.14.
>>>>>> <https://sourceforge.net/projects/iperf2/>  This is probably an
>>>>>> experimental feature that could be added last minute.  We'd need you to
>>>>>> test if willing. Our goal is to release 2.0.14 early 2021.
>>>>>>
>>>>>> We're out of short options and would need to use long options. Maybe
>>>>>> something like
>>>>>>
>>>>>> --sweep-range=1m,100m, 1m (start, final, step size) defaults to
>>>>>> 1m,10m,1m with just --sweep-range
>>>>>> --sweep-steptime 1.5 (units of seconds) defaults to 1 second if
>>>>>> --sweep-range and no --sweep-steptime
>>>>>>
>>>>>> Note that --sweep-range has optional arguments (per the =) and
>>>>>> sweep-steptime has a mandatory argument (if used.)
>>>>>>
>>>>>> All, do comment on more intuitive command line options.
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> On Tue, Dec 1, 2020 at 8:12 AM Craig Reeves <
>>>>>> craigree...@ambit-llc.com> wrote:
>>>>>>
>>>>>>> First, many thanks for putting this tool together and sharing it.
>>>>>>> It has proved invaluable over the years when dealing with ISPs.
>>>>>>>
>>>>>>> That being said, we regularly encounter ISPs that don't think their
>>>>>>> network has issues.  Most of the time we can pinpoint to a switch or
>>>>>>> connection that is over saturated.
>>>>>>>
>>>>>>> I would love to see a feature that allowed us to set a starting
>>>>>>> throughput, incremental step up/down throughput, and interval.  This 
>>>>>>> would
>>>>>>> help find the point at which issues begin.  Here is the idea:
>>>>>>>
>>>>>>> iperf3 -c 192.168.1.100 -bt 1M -et 10M -st 10s -t 100 -u
>>>>>>>
>>>>>>> -bt = beginning throughput
>>>>>>> -et = ending throughput
>>>>>>> -st = step up/down time
>>>>>>>
>>>>>>> The thinking is that iperf3 would start a test (UDP or TCP) at 1Mb/s
>>>>>>> throughput, and then ramp up in 1Mb/s steps ever 10 seconds.
>>>>>>>
>>>>>>> This eliminates the need to do individual runs with different
>>>>>>> settings.
>>>>>>>
>>>>>>> Thank you,
>>>>>>>
>>>>>>> Craig Reeves
>>>>>>>
>>>>>>> ___
>>>>>>> Iperf-users mailing list
>>>>>>> Iperf-users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>>>>>
>>>>>>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

Also, this would only be on the client. Iperf 2.0.14 supports both write
and read rate limiting via -b on the server as well as client.  Sweeps
wouldn't be supported by the server (or on the read side.)

Any issue with that, or, is there a read size need as well?

Bob

On Tue, Dec 1, 2020 at 11:29 AM Craig Reeves 
wrote:

> Bob,
>
> Thanks, we'd be more than happy to test it out.  Just let me know and I'll
> get my engineering group to check it out.
>
> Craig Reeves
>
> "Bridging Communications"
> 3520 Lorna Ridge Drive
> Hoover, AL 35216
> v.(205) 829-1800
> f. (205) 536-6333
> c. (205) 332-5916
>
>
> On Tue, Dec 1, 2020 at 1:21 PM Bob McMahon 
> wrote:
>
>> Hi Craig,
>>
>> Any reason you need iperf 3 for this and can't use iperf 2.0.14?
>>
>> We are in the process of early field test for iperf 2.0.14.
>> <https://sourceforge.net/projects/iperf2/>  This is probably an
>> experimental feature that could be added last minute.  We'd need you to
>> test if willing. Our goal is to release 2.0.14 early 2021.
>>
>> We're out of short options and would need to use long options. Maybe
>> something like
>>
>> --sweep-range=1m,100m, 1m (start, final, step size) defaults to 1m,10m,1m
>> with just --sweep-range
>> --sweep-steptime 1.5 (units of seconds) defaults to 1 second if
>> --sweep-range and no --sweep-steptime
>>
>> Note that --sweep-range has optional arguments (per the =) and
>> sweep-steptime has a mandatory argument (if used.)
>>
>> All, do comment on more intuitive command line options.
>>
>> Bob
>>
>>
>>
>> Bob
>>
>> On Tue, Dec 1, 2020 at 8:12 AM Craig Reeves 
>> wrote:
>>
>>> First, many thanks for putting this tool together and sharing it.  It
>>> has proved invaluable over the years when dealing with ISPs.
>>>
>>> That being said, we regularly encounter ISPs that don't think their
>>> network has issues.  Most of the time we can pinpoint to a switch or
>>> connection that is over saturated.
>>>
>>> I would love to see a feature that allowed us to set a starting
>>> throughput, incremental step up/down throughput, and interval.  This would
>>> help find the point at which issues begin.  Here is the idea:
>>>
>>> iperf3 -c 192.168.1.100 -bt 1M -et 10M -st 10s -t 100 -u
>>>
>>> -bt = beginning throughput
>>> -et = ending throughput
>>> -st = step up/down time
>>>
>>> The thinking is that iperf3 would start a test (UDP or TCP) at 1Mb/s
>>> throughput, and then ramp up in 1Mb/s steps ever 10 seconds.
>>>
>>> This eliminates the need to do individual runs with different settings.
>>>
>>> Thank you,
>>>
>>> Craig Reeves
>>>
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Feature - Throughput ramp up

[Bob McMahon via Iperf-users]

Hi Craig,

Any reason you need iperf 3 for this and can't use iperf 2.0.14?

We are in the process of early field test for iperf 2.0.14.
  This is probably an
experimental feature that could be added last minute.  We'd need you to
test if willing. Our goal is to release 2.0.14 early 2021.

We're out of short options and would need to use long options. Maybe
something like

--sweep-range=1m,100m, 1m (start, final, step size) defaults to 1m,10m,1m
with just --sweep-range
--sweep-steptime 1.5 (units of seconds) defaults to 1 second if
--sweep-range and no --sweep-steptime

Note that --sweep-range has optional arguments (per the =) and
sweep-steptime has a mandatory argument (if used.)

All, do comment on more intuitive command line options.

Bob



Bob

On Tue, Dec 1, 2020 at 8:12 AM Craig Reeves 
wrote:

> First, many thanks for putting this tool together and sharing it.  It has
> proved invaluable over the years when dealing with ISPs.
>
> That being said, we regularly encounter ISPs that don't think their
> network has issues.  Most of the time we can pinpoint to a switch or
> connection that is over saturated.
>
> I would love to see a feature that allowed us to set a starting
> throughput, incremental step up/down throughput, and interval.  This would
> help find the point at which issues begin.  Here is the idea:
>
> iperf3 -c 192.168.1.100 -bt 1M -et 10M -st 10s -t 100 -u
>
> -bt = beginning throughput
> -et = ending throughput
> -st = step up/down time
>
> The thinking is that iperf3 would start a test (UDP or TCP) at 1Mb/s
> throughput, and then ramp up in 1Mb/s steps ever 10 seconds.
>
> This eliminates the need to do individual runs with different settings.
>
> Thank you,
>
> Craig Reeves
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Server/Client buffer size -d

[Bob McMahon via Iperf-users]

Try the docs and let me know.

https://sourceforge.net/p/iperf2/code/ci/master/tree/INSTALL

Bob

On Fri, Nov 20, 2020 at 1:35 PM Valerio Scheleter <
valerio.schele...@virginorbit.com> wrote:

> Hi Bob,
>
> Thanks for your response. I honestly don't know how to build it from the
> source code. Have anyone done it already and I can access that?
>
> Thank you,
>
> Valerio
>
> -----Original Message-
> From: Bob McMahon [mailto:bob.mcma...@broadcom.com]
> Sent: Thursday, November 19, 2020 11:47 AM
> To: Valerio Scheleter 
> Cc: iperf-users@lists.sourceforge.net
> Subject: Re: [Iperf-users] Server/Client buffer size -d
>
>
>
> [EXTERNAL EMAIL]
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Server/Client buffer size -d

[Bob McMahon via Iperf-users]

Probably a bug.  Can you try 2.0.14
? You will have to compile from
source.

Bob

On Thu, Nov 19, 2020 at 11:22 AM Valerio Scheleter via Iperf-users <
iperf-users@lists.sourceforge.net> wrote:

> Hello everyone,
>
>
>
> I am using iperf 2.0.9 with 1 client and 1 server with the option -d in
> order to have a dual test.
>
> From the documentation showed below, I can specify using –L the port that
> the server will connect back to the client, but I don’t see anything where
> I can specify the buffer size of the dual test.
>
>
>
> In my test I set the buffer size to 50MB for both Server and Client (-w
> 50M) and on the Client Linux machine I see both being 50MB.
>
> But for the Server Windows machine, I see the client connecting with a
> lower buffer size which depends on the bandwidth selected. (picture below)
>
>
>
>
>
> Is there a way I can set the buffer size for both of the buffer to 50MB?
>
> Am I missing something?
>
>
>
> Specifically the commands I am using are:
>
>
>
> *Server:* iperf -s -u -i 1 -w 50M -p 510  -b 2M  -B 172.16.1.101 –l 45000
>
> *Client: *iperf -c -172.16.1.101  -t 10  -u -i 1  -w 50MB  -b 2MB  -d  -p
> 510 –l 45
>
>
>
> Thanks,
>
>
>
> Valerio
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] pressure for better clocks

[Bob McMahon via Iperf-users]

Hi All,

Iperf 2.0.14 provides end/end latency measurements but requires sync'ed
clocks. The lack of attention to latency is a major deficit to the
networking industry and impairs user experience.

I find one of the many problems with the tech industry is that cheap mass
market stuff proliferates.  An example of this is the oscillators used for
time keeping which run things like CPUs.  There are many ways to get better
time without spending too much. The GPS atomic clocks are basically
available for free over most of the planet. Cellular clocks, synced to GPS,
are available indoors.

Here is a good article:

https://www.pcworld.com/article/2891892/why-computers-still-struggle-to-tell-the-time.html



*But computer makers often use inexpensive crystals costing only a few
cents each, which can compromise accuracy. “If you buy server-class
hardware, you will get cheap crystal, and time will wander if you don’t do
something about it,” Neville-Neil said.The average crystal ends up being
about as accurate as a mechanical watch*

Bob McMahon


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2.0.14 EFT phase 2

[Bob McMahon via Iperf-users]

Hi All,

We're starting phase 2 EFT for iperf 2.0.14
. What defines phase 2 is that
the shirts have arrived. Please do test this version. File a few bugs,
suggest some output changes, or provide a patch and we'll send you some
swag.

Also, a key component of iperf 2.0.14 is around end to end or write to read
latencies. This is a crucial metric. The past focus of iperf has been
throughput or capacity without regard to latency or speed. It would be
great if folks tried this out.  The --trip-times option is required. Also,
please synchronize your clocks with IEEE 1588 or PTP.

Also note, we've added a full-duplex option. I don't think this has been
tested before as we're seeing issues with full duplex sockets using 100G
NICs and linux.

Here are the latest release notes:

2.0.14 change set (as of October 14th, 2020)

o scaling improvements for -P, i.e. improved support for large numbers of
traffic threads
o major code refactoring (see doc/DESIGN_NOTES) for maintainability,
extensibility, performance, scaling, memory usage
o support for full duplex traffic using --full-duplex
o support for reverse traffic using --reverse
o support for role-reversal character of asterisk in the transfer id
o transfer id now an incrementing integer and no longer the socket id
o support for TCP connect only tests with --connect-only
o isochronous support compiled in by default, must use config to disable
o support --isochronous for both UDP or TCP traffic to simulate video
streams
o use of clock_nanosleep when supported to schedule isochronous burst
starts, otherwise use nanosleep delay
o support for --trip-times indicating the client and server clocks are
synchronized to an accuracy sufficient, note: consider the use of precision
time protocol as well as ask your data center to provide access to a GPS
disciplined reference time source
o support for --trip-times with -d and -r bidirectional tests
o output TCP connect times (3WHS) in connect reports
o rate-limited options of -b and --fq-rate supported for unidirectional,
full duplex and reverse traffic
o reporter thread designed to automatically cause packet reports to
aggregate - mitigating and hopefully removing thread thrashing
o support for frame or burst based reporting or sampling vs time based via
-i [f|F] (experimental)
o support for UDP traffic only from client to server with --no-udp-fin
o support for write to read latencies (UDP and TCP) with --trip-times
o support for sum only outputs with --sum-only
o support for little's law calculations in --trip-time outputs
o support for --txstart-time  to schedule client traffic start,
timestamp support microseconds, e.g. unix $(expr $(date +%s) + 1).$(date
+%N)
o support for --txdelay-time to insert delay between TCP three way
handshake (3WHS) and data transfer
o support for --no-connect-sync which disables transmit traffic start
synchronization when -P is used, defaults to synchronized
o option of --full-duplex implementation uses a barrier on the client side
to synchronize full duplex traffic
o no limits to group sum reports, i.e. all clients will get its own sum
report per a server
o improved report timestamps, e.g. end to end or client and server based
timestamps with --trip-times
o improved settings messaging
o improved messaging for --tcp-congestion or -Z
o re-implemented -U for single UDP server with minimal threading
interactions
o re-implemented -1 or --singleclient where server will serialize traffic
runs
o warning message if the test were likely CPU bound instead of network i/o
bound
o fix the case when -P  is set on the server such that summing
output is displayed
o multicast listener will autoset -U (single server), e.g -P > 1 not
supported for multicast
o multicast listener no longer busy drops multicast packets during traffic
test, i.e. only server thread receives them
o immediate bail out on mutually exclusive command line options
o man page updates with examples
o tested with 1000's of traffic streams, WiFi, 10G and 100G

Bob


smime.p7s
Description: S/MIME Cryptographic Signature
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2.0.14 --sum-only option and TCP client ending timestamp

[Bob McMahon via Iperf-users]

Hi All,

We're adding a --sum-only option to iperf 2.0.14.  This is useful for
scaling the number of traffic threads to large values. Here is a sample
output:

[rjmcmahon@localhost iperf2-code]$ src/iperf -c 192.168.1.10 -i 1 -P 1000
--sum-only
[SUM-1000]  0.0- 1.0 sec  1.57 GBytes  13.5 Gbits/sec
[SUM-1000]  1.0- 2.0 sec  1.12 GBytes  9.65 Gbits/sec
[SUM-1000]  2.0- 3.0 sec  1.11 GBytes  9.50 Gbits/sec
[SUM-1000]  3.0- 4.0 sec  1.11 GBytes  9.51 Gbits/sec
[SUM-1000]  4.0- 5.0 sec  1.10 GBytes  9.41 Gbits/sec
[SUM-1000]  5.0- 6.0 sec  1.09 GBytes  9.40 Gbits/sec
[SUM-1000]  6.0- 7.0 sec  1.10 GBytes  9.45 Gbits/sec
[SUM-1000]  7.0- 8.0 sec  1.09 GBytes  9.40 Gbits/sec
[SUM-1000]  8.0- 9.0 sec  1.10 GBytes  9.41 Gbits/sec
[SUM-1000]  9.0-10.4 sec  1.34 GBytes  8.47 Gbits/sec
[SUM-1000]  0.0-10.4 sec  11.7 GBytes  9.73 Gbits/sec

I also wanted to get feedback on iperf client timestamps. Particularly on
what exactly constitutes a writer as done?  Is it when the last write
completes on the client host, when the writer issues a socket close(), or
when the writer detects a reader (server) shutdown()
 event, i.e. the FIN, FINACK
handshake? None of these are perfect as there are OS and network
interactions in play for all of them which are difficult to decouple. The
first two will cause a timestamp to be a bit early as the OS hasn't
finished draining the socket even though the application thread is done and
destroyed.  We've chosen to await for the FINACK per the following in the
upcoming release of iperf 2.0.14

int rc = recv(mySocket, , 1, MSG_DONTWAIT|MSG_PEEK);
if (rc==0 || !NONFATALTCPREADERR(errno)) {
#ifdef HAVE_THREAD_DEBUG
thread_debug("Client detected server close %d", mySocket);
#endif
break;


More Background:

We've implemented the --trip-times option so that iperf server will be able
to give end/end performance at the application level.  With --trip-times
the start stamp is taken from the first write vs., without, it's taken from
the first read. Also, write timestamps go into bursts so the timing is
exactly what a customer will experience.

Thanks for thoughts and comments,
Bob
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] [UDP test] Increasing bitrate not increase the packet loss

[Bob McMahon via Iperf-users]

Not at an intermediate network but at the host computer (or VM) that is
transmitting

Bob

On Sun, Aug 2, 2020 at 6:49 PM Zufar Dhiyaulhaq 
wrote:

> Hi Bob and Tim,
>
> Thank you for responding to my question. sometime today will try
> increasing the window. Since I am testing this in a virtual environment
> (OpenStack), it is hard to define the wire limitation. I get UDP throughput
> somewhere between 100-120 Mbps and TCP throughput between 50-100 Mbps
> (using 1402 (GENEVE) & 1410 (VXLAN) mss since I am using tunneling
> protocol).
>
> In the case of UDP that Bob saying. so the limitation you said is in the
> intermediate network, right? so the client will force to send all packet
> (by increasing window size) but will get dropped in the intermediate net?
>
> Best Regards,
> Zufar Dhiyaulhaq
>
>
> On Mon, Aug 3, 2020 at 2:05 AM Bob McMahon 
> wrote:
>
>> If the bottleneck is the transmitter's wire that means things will back
>> up behind that.  The network stack on the client will queue packets.  Since
>> it's in a state of oversubscription there is no way for the client to ever
>> drain the bottleneck so-to-speak.  A bottleneck is when the service time is
>> less than the arrival time.  So one host to look more closely at the client
>> host, where the bottleneck is, to understand.  There are two things
>> happening, iperf is issuing writes() and the network stack is sending
>> packets. While related, they're different.
>>
>> The iperf client issues a write() to cause the sending of a packet.  If
>> the operating system has system buffers it will accept the write()
>> otherwise it has two choices, block or suspend the write until a system
>> buffer comes available or error on the write.  What I suspect you're seeing
>> is an os blocking on the write().  Increasing the window size will allow
>> the os to accept the write and pass the packet to the network stack, which
>> will in turn drop the packet.  Then you'll see packet loss.
>>
>> Did you try with a bigger window?
>>
>> Bob
>>
>> On Fri, Jul 31, 2020 at 4:29 PM Zufar Dhiyaulhaq <
>> zufardhiyaul...@gmail.com> wrote:
>>
>>> Hi Bob,
>>>
>>> Thanks for replying. In my understanding, when increasing the bitrate
>>> above the bandwidth/throughput, it will increase the packet loss right? but
>>> in my case, I increase to 9 Gbps and still not seeing any packet loss. Did
>>> increasing window size will increasing packet loss? and why that can happen?
>>>
>>> I am trying to simulate packet loss.
>>>
>>> Thanks
>>>
>>> Best Regards,
>>> Zufar Dhiyaulhaq
>>>
>>>
>>> On Sat, Aug 1, 2020 at 5:28 AM Bob McMahon 
>>> wrote:
>>>
>>>> Try to increase the window size with -w on the client.  This will allow
>>>> the operating system to accept the write and drop packets within the
>>>> stack.  If the window is too small the operating system will block the
>>>> write until os buffers are available.
>>>>
>>>> Bob
>>>>
>>>> On Fri, Jul 31, 2020 at 8:56 AM Zufar Dhiyaulhaq <
>>>> zufardhiyaul...@gmail.com> wrote:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I have a problem with iperf3, I try to simulate packet loss with
>>>>> Iperf3 with increasing the bitrate above the bandwidth. But packet loss
>>>>> output not increasing.
>>>>>
>>>>> Ubuntu 18.04
>>>>> Iperf 3.7.3
>>>>>
>>>>> I don't know why this is happening? Is there any bug with Iperf? this
>>>>> sounds stupid for me.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *ubuntu@vm1:~$ iperf3 -c 192.168.0.92 --udp -t 20 --bitrate 9000m -R
>>>>> -Viperf 3.7Linux vm1 4.15.0-112-generic #113-Ubuntu SMP Thu 

Re: [Iperf-users] [UDP test] Increasing bitrate not increase the packet loss

[Bob McMahon via Iperf-users]

If the bottleneck is the transmitter's wire that means things will back up
behind that.  The network stack on the client will queue packets.  Since
it's in a state of oversubscription there is no way for the client to ever
drain the bottleneck so-to-speak.  A bottleneck is when the service time is
less than the arrival time.  So one host to look more closely at the client
host, where the bottleneck is, to understand.  There are two things
happening, iperf is issuing writes() and the network stack is sending
packets. While related, they're different.

The iperf client issues a write() to cause the sending of a packet.  If the
operating system has system buffers it will accept the write() otherwise it
has two choices, block or suspend the write until a system buffer comes
available or error on the write.  What I suspect you're seeing is an os
blocking on the write().  Increasing the window size will allow the os to
accept the write and pass the packet to the network stack, which will in
turn drop the packet.  Then you'll see packet loss.

Did you try with a bigger window?

Bob

On Fri, Jul 31, 2020 at 4:29 PM Zufar Dhiyaulhaq 
wrote:

> Hi Bob,
>
> Thanks for replying. In my understanding, when increasing the bitrate
> above the bandwidth/throughput, it will increase the packet loss right? but
> in my case, I increase to 9 Gbps and still not seeing any packet loss. Did
> increasing window size will increasing packet loss? and why that can happen?
>
> I am trying to simulate packet loss.
>
> Thanks
>
> Best Regards,
> Zufar Dhiyaulhaq
>
>
> On Sat, Aug 1, 2020 at 5:28 AM Bob McMahon 
> wrote:
>
>> Try to increase the window size with -w on the client.  This will allow
>> the operating system to accept the write and drop packets within the
>> stack.  If the window is too small the operating system will block the
>> write until os buffers are available.
>>
>> Bob
>>
>> On Fri, Jul 31, 2020 at 8:56 AM Zufar Dhiyaulhaq <
>> zufardhiyaul...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> I have a problem with iperf3, I try to simulate packet loss with Iperf3
>>> with increasing the bitrate above the bandwidth. But packet loss output not
>>> increasing.
>>>
>>> Ubuntu 18.04
>>> Iperf 3.7.3
>>>
>>> I don't know why this is happening? Is there any bug with Iperf? this
>>> sounds stupid for me.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *ubuntu@vm1:~$ iperf3 -c 192.168.0.92 --udp -t 20 --bitrate 9000m -R
>>> -Viperf 3.7Linux vm1 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39
>>> UTC 2020 x86_64Control connection MSS 1390Setting UDP block size to
>>> 1390Time: Fri, 31 Jul 2020 15:53:39 GMTConnecting to host 192.168.0.92,
>>> port 5201Reverse mode, remote host 192.168.0.92 is sending  Cookie:
>>> geu5ktrvwtalkelbszen5ym4rzxfp5xgzwdy  Target Bitrate: 90[  5]
>>> local 192.168.0.226 port 47999 connected to 192.168.0.92 port 5201Starting
>>> Test: protocol: UDP, 1 streams, 1390 byte blocks, omitting 0 seconds, 20
>>> second test, tos 0[ ID] Interval   Transfer Bitrate
>>> JitterLost/Total Datagrams[  5]   0.00-1.00   sec  13.8 MBytes   116
>>> Mbits/sec  0.081 ms  269/10704 (2.5%)  [  5]   1.00-2.00   sec  13.7 MBytes
>>>   115 Mbits/sec  0.085 ms  0/10346 (0%)  [  5]   2.00-3.00   sec  13.6
>>> MBytes   114 Mbits/sec  0.035 ms  126/10365 (1.2%)  [  5]   3.00-4.00   sec
>>>  12.8 MBytes   107 Mbits/sec  0.033 ms  279/9946 (2.8%)  [  5]   4.00-5.00
>>>   sec  13.5 MBytes   113 Mbits/sec  0.051 ms  262/10427 (2.5%)  [  5]
>>> 5.00-6.00   sec  13.2 MBytes   111 Mbits/sec  0.058 ms  0/9965 (0%)  [  5]
>>>   6.00-7.00   sec  13.3 MBytes   111 Mbits/sec  0.044 ms  32/10047 (0.32%)
>>>  [  5]   7.00-8.00   sec  13.0 MBytes   109 Mbits/sec  0.053 ms  43/9874
>>> (0.44%)  [  5]   8.00-9.00   sec  13.0 MBytes   109 Mbits/sec  0.042 ms
>>>  34/9847 (0.35%)  [  5]   9.00-10.00  sec  13.6 MBytes   114 Mbits/sec
>>>  0.055 ms  78/10305 (0.76%)  [  5]  10.00-11.00  sec  13.5 MBytes   113
>>> Mbits/sec  0.070 ms  0/10171 (0%)  [  5]  11.00-12.00  sec  13.1 MBytes
>>> 110 Mbits/sec  0.047 ms  0/9851 (0%)  [  5]  12.00-13.00  sec  13.3 MByt

Re: [Iperf-users] [UDP test] Increasing bitrate not increase the packet loss

[Bob McMahon via Iperf-users]

Try to increase the window size with -w on the client.  This will allow the
operating system to accept the write and drop packets within the stack.  If
the window is too small the operating system will block the write until os
buffers are available.

Bob

On Fri, Jul 31, 2020 at 8:56 AM Zufar Dhiyaulhaq 
wrote:

> Hi Folks,
>
> I have a problem with iperf3, I try to simulate packet loss with Iperf3
> with increasing the bitrate above the bandwidth. But packet loss output not
> increasing.
>
> Ubuntu 18.04
> Iperf 3.7.3
>
> I don't know why this is happening? Is there any bug with Iperf? this
> sounds stupid for me.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *ubuntu@vm1:~$ iperf3 -c 192.168.0.92 --udp -t 20 --bitrate 9000m -R
> -Viperf 3.7Linux vm1 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39
> UTC 2020 x86_64Control connection MSS 1390Setting UDP block size to
> 1390Time: Fri, 31 Jul 2020 15:53:39 GMTConnecting to host 192.168.0.92,
> port 5201Reverse mode, remote host 192.168.0.92 is sending  Cookie:
> geu5ktrvwtalkelbszen5ym4rzxfp5xgzwdy  Target Bitrate: 90[  5]
> local 192.168.0.226 port 47999 connected to 192.168.0.92 port 5201Starting
> Test: protocol: UDP, 1 streams, 1390 byte blocks, omitting 0 seconds, 20
> second test, tos 0[ ID] Interval   Transfer Bitrate
> JitterLost/Total Datagrams[  5]   0.00-1.00   sec  13.8 MBytes   116
> Mbits/sec  0.081 ms  269/10704 (2.5%)  [  5]   1.00-2.00   sec  13.7 MBytes
>   115 Mbits/sec  0.085 ms  0/10346 (0%)  [  5]   2.00-3.00   sec  13.6
> MBytes   114 Mbits/sec  0.035 ms  126/10365 (1.2%)  [  5]   3.00-4.00   sec
>  12.8 MBytes   107 Mbits/sec  0.033 ms  279/9946 (2.8%)  [  5]   4.00-5.00
>   sec  13.5 MBytes   113 Mbits/sec  0.051 ms  262/10427 (2.5%)  [  5]
> 5.00-6.00   sec  13.2 MBytes   111 Mbits/sec  0.058 ms  0/9965 (0%)  [  5]
>   6.00-7.00   sec  13.3 MBytes   111 Mbits/sec  0.044 ms  32/10047 (0.32%)
>  [  5]   7.00-8.00   sec  13.0 MBytes   109 Mbits/sec  0.053 ms  43/9874
> (0.44%)  [  5]   8.00-9.00   sec  13.0 MBytes   109 Mbits/sec  0.042 ms
>  34/9847 (0.35%)  [  5]   9.00-10.00  sec  13.6 MBytes   114 Mbits/sec
>  0.055 ms  78/10305 (0.76%)  [  5]  10.00-11.00  sec  13.5 MBytes   113
> Mbits/sec  0.070 ms  0/10171 (0%)  [  5]  11.00-12.00  sec  13.1 MBytes
> 110 Mbits/sec  0.047 ms  0/9851 (0%)  [  5]  12.00-13.00  sec  13.3 MBytes
>   112 Mbits/sec  0.034 ms  0/10055 (0%)  [  5]  13.00-14.00  sec  13.4
> MBytes   112 Mbits/sec  0.040 ms  36/10136 (0.36%)  [  5]  14.00-15.00  sec
>  13.9 MBytes   117 Mbits/sec  0.055 ms  437/10921 (4%)  [  5]  15.00-16.00
>  sec  13.2 MBytes   111 Mbits/sec  0.043 ms  25/9964 (0.25%)  [  5]
>  16.00-17.00  sec  13.2 MBytes   110 Mbits/sec  0.043 ms  21/9942 (0.21%)
>  [  5]  17.00-18.00  sec  12.9 MBytes   108 Mbits/sec  0.046 ms  0/9702
> (0%)  [  5]  18.00-19.00  sec  13.4 MBytes   112 Mbits/sec  0.050 ms
>  208/10294 (2%)  [  5]  19.00-20.00  sec  13.5 MBytes   113 Mbits/sec
>  0.048 ms  0/10152 (0%)  - - - - - - - - - - - - - - - - - - - - - - - -
> -Test Complete. Summary Results:[ ID] Interval   Transfer
> Bitrate JitterLost/Total Datagrams[  5]   0.00-20.04  sec   269
> MBytes   113 Mbits/sec  0.000 ms  0/203058 (0%)  sender[  5]   0.00-20.00
>  sec   267 MBytes   112 Mbits/sec  0.048 ms  1850/203014 (0.91%)  receiver*
>
> Thank you
>
> Best Regards,
> Zufar Dhiyaulhaq
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Filecopy only fast with iperf runs simultaneously

[Bob McMahon via Iperf-users]

What version of iperf? Use iperf -v to tell. If you're using iperf 2.0.13
 try posting the output of
interval reports, -i 1 e.g., on both the client and server (tcp) along with
the enhanced reports (use -e) for both cases, no SAMBA traffic and with
concurrent SAMBA traffic.  Also, describe the network, e.g. WiFi, 1G, 10G,
and the machines a bit, e.g. number of CPUs.

Bob

On Sun, Jul 19, 2020 at 12:07 AM tomas jupe via Iperf-users <
iperf-users@lists.sourceforge.net> wrote:

> Hey,
>
> I run "iperf -s" on the samba server and "iperf -c IP-ADDRESS -t 60" on
> another machine (linux or windows, tried both) while I simultaneously copy
> the files to a machine in the network using the windows file-explorer.
>
> Only when iperf is running (with either protocols, TCP or UDP) the copying
> process gets way faster (from around 100 Kbit/s to 100 Mbit/s).
>
> It is indeed a very interesting effect, and i cant explain where it comes
> from.
>
> Thank you for any tip or idea.
>
>
> Am 18.07.20 um 22:48 schrieb Sascha Osdoba:
>
> hi,
>
> please tell the command line to run iperf on server.
>
> regards
>
> 18.07.2020 20:09:54 tomas jupe via Iperf-users
>  :
>
> Thank you very much for your idea.
>
> At first it looked like a possible solution. The CPU-usage is higher with
> iperf running (from ~6% to ~25%).
>
> But when i run "stress" to throttle up the cpu to 100%, the speed of the
> copying process is not getting faster.
>
> Only with iperf running the files are copied faster...
>
>
> So i am still searching for a solution.
>
> Am 18.07.20 um 18:46 schrieb Vince Conroy:
>
> This might be a long shot, but maybe the cpu on one or both PCs is being
> throttled (reduced clock speed) because of a power setting and running
> iperf causes it to throttle up?
>
> On Sat, Jul 18, 2020, 9:18 AM tomas jupe via Iperf-users <
> iperf-users@lists.sourceforge.net> wrote:
>
>> Hi all,
>>
>>
>> My Samba server only copies files fast when iperf is also running
>> simultaneously.
>>
>>
>> I have a samba setup to access files from a Windows-PC. Sadly
>> transferring files to it and from it is very slow.
>>
>> (The windows-pcs are part of a domain managed by the samba server)
>>
>> Especially when a large number of small files are copied the speed is
>> very low. Large files are copied quite fast.
>>
>> But as soon as a start a speedtest with iperf from another machine to
>> that samba server the speed of copying files from the samba server is
>> way faster.
>>
>> As soon as iperf stops the speed of the file copy drops again.
>>
>>
>> Does anyone has an idea why iperf is improving the speed of copying the
>> files from a samba server? And what do i have to change in my network to
>> keep the high speed. :)
>>
>>
>> Any help is much appreciated.
>>
>> Thank you very much.
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Iperf-users mailing list
>> Iperf-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
> Vince Conroy
> West Wave Technology
> 707.890.6620
>
>
>
> ___
> Iperf-users mailing 
> listIperf-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/iperf-users
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Multicast

[Bob McMahon via Iperf-users]

What version of iperf  where iperf -v should show this?  Also, can you show
the server and client side commands used?  Finally, what operating system?

Bob

On Mon, May 4, 2020 at 7:47 AM Andrew Morcos 
wrote:

> Hello guys,
>
> So I'm trying to bind multiple interfaces on a VM to a multicast address.
> And I'm running client iperf on another VM to this multicast address. Why
> can't I receive any info on the server sides? What do you think should I
> do?
> Thank you!
>
> Andrew Morcos
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Negative Latency

[Bob McMahon via Iperf-users]

There is no such thing as RTT on UDP packets, that's only for TCP.  You're
likely getting negative latencies for UDP because the clocks of the client
and server aren't synchronized to a common quality time referençe.

Bob

On Sun, Apr 19, 2020 at 2:06 PM Andrew Morcos 
wrote:

>
>
> Hello everyone,
>
>
>
> Hope you’re doing well !
>
>
>
> I have a question concerning iperf tests. I’ve been getting a negative
> value of latency(RTT) for UDP packets with the options -u (UDP) -e ( to
> display avg/max/min RTT).
>
> I can’t find on Internet, the reason behind obtaining such results or what
> does this mean.
>
> If anyone has an answer, you’ll be helping me !
>
> Thank you !
>
>
>
> Andrew Morcos
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf latency measures

[Bob McMahon via Iperf-users]

The TCP display on the client is the round trip time (RTT)  This is sampled
per the network stack.

Note that with 2.0.14 and the --trip-times option there is an
application level latency as well. It's the client's write() start time to
the server's final read of that write.  For --isochronous the latencies are
per each frame or burst.

For many cases what users care most about is end/end or application to
application latency.  It's network stack engineers that typically care
about RTT

Bob

On Thu, Apr 16, 2020 at 12:00 PM Andrew Morcos 
wrote:

> Hello M. McMahon
> Thank you for your answer!
> Concerning TCP packets, does it find the latency based on the time the
> clients receives an acknowledgment?
> Thank you!
>
> ANDREW MORCOS
>
>
> Sent from my Huawei phone
>
>
> ---- Original message 
> From: Bob McMahon 
> Date: Thu, Apr 16, 2020, 8:57 PM
> To: Andrew Morcos 
> Cc: iperf-users@lists.sourceforge.net
> Subject: Re: [Iperf-users] Iperf latency measures
>
> The UDP latency assumes the two clocks are synchronized. The GPS atomic
> clocks are suggested as a common reference.  IEEE 1588 or Precision Time
> Protocol (PTP) is suggested (over things like network time protocol NTP) to
> distribute a reference clock. For a bench test environment one could use
> the clock on a device and distribute it to the other using(s) PTP. A final
> option is to use your own local oscillator and distribute that.  I use oven
> controlled oscillators (OCXO) by spectracom, e.g. their tsync pcie cards.
>
> Note: In 2.0.14, currently under development, these values will own show
> up if the --trip-times option is set on the client. This basically
> indicates to iperf that the user is claiming the clocks have somehow been
> synchronized.  There are a bunch more latency related features as well.  
> videos
> can be found here
> <https://www.youtube.com/channel/UCaqlH3a442xaZ9humrxRHGQ/>
>
> Bob
>
> On Thu, Apr 16, 2020 at 10:35 AM Andrew Morcos 
> wrote:
>
> Hello everyone,
>
> I have a question concerning how Iperf can determine some values.
> So when using Iperf for capturing network information such as throuput,
> packets loss etc.. There's an option "-e" that gives as an output the
> LATENCY as well (average/max/min RTT). It works as well for UDP packets.
> Does anyone know how could Iperf measure LATENCY for UDP packets since UDP
> packets are unacknowledged?
>
> Thank you.
>
> Andrew Morcos
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_-3194983896188525430_m_3408531035212424192_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf latency measures

[Bob McMahon via Iperf-users]

The UDP latency assumes the two clocks are synchronized. The GPS atomic
clocks are suggested as a common reference.  IEEE 1588 or Precision Time
Protocol (PTP) is suggested (over things like network time protocol NTP) to
distribute a reference clock. For a bench test environment one could use
the clock on a device and distribute it to the other using(s) PTP. A final
option is to use your own local oscillator and distribute that.  I use oven
controlled oscillators (OCXO) by spectracom, e.g. their tsync pcie cards.

Note: In 2.0.14, currently under development, these values will own show up
if the --trip-times option is set on the client. This basically indicates
to iperf that the user is claiming the clocks have somehow been
synchronized.  There are a bunch more latency related features as well.  videos
can be found here


Bob

On Thu, Apr 16, 2020 at 10:35 AM Andrew Morcos 
wrote:

> Hello everyone,
>
> I have a question concerning how Iperf can determine some values.
> So when using Iperf for capturing network information such as throuput,
> packets loss etc.. There's an option "-e" that gives as an output the
> LATENCY as well (average/max/min RTT). It works as well for UDP packets.
> Does anyone know how could Iperf measure LATENCY for UDP packets since UDP
> packets are unacknowledged?
>
> Thank you.
>
> Andrew Morcos
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_3408531035212424192_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Cygwin1.dll out of date

[Bob McMahon via Iperf-users]

I just checked with our windows engineer and he said the iperf 2
team no longer uses cygwin but
rather builds a native version.

Bob

On Tue, Feb 4, 2020 at 2:07 PM Daniel Havey  wrote:

> Hi, I'm Daniel Havey from Microsoft Windows.  I'm the PM for transports
> (TCP/QUIC) and there is a bug in the cygwin1.dll that was distributed with
> the iperf binaries.  The bug limits maximum bandwidth achievable by the
> iperf tool.  Details can be found in my blogpost:
> https://techcommunity.microsoft.com/t5/networking-blog/windows-network-performance-suffering-from-bad-buffering/ba-p/339668
>
> We worked with RedHat on Cygwin to fix the bug, but I am still getting
> reports of limited bandwidth from windows iperf users.  The fix is simple.
> Just download the new cygwin1.dll from the cygwin website and the problem
> will be fixed.
>
> thanks ;)
> ...Daniel
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Cygwin1.dll out of date

[Bob McMahon via Iperf-users]

Cool, thanks for this

Bob

On Tue, Feb 4, 2020 at 2:07 PM Daniel Havey  wrote:

> Hi, I'm Daniel Havey from Microsoft Windows.  I'm the PM for transports
> (TCP/QUIC) and there is a bug in the cygwin1.dll that was distributed with
> the iperf binaries.  The bug limits maximum bandwidth achievable by the
> iperf tool.  Details can be found in my blogpost:
> https://techcommunity.microsoft.com/t5/networking-blog/windows-network-performance-suffering-from-bad-buffering/ba-p/339668
>
> We worked with RedHat on Cygwin to fix the bug, but I am still getting
> reports of limited bandwidth from windows iperf users.  The fix is simple.
> Just download the new cygwin1.dll from the cygwin website and the problem
> will be fixed.
>
> thanks ;)
> ...Daniel
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Cygwin1.dll out of date

[Bob McMahon via Iperf-users]

Bruce Mah at es net is my main iperf 3 contact.

Not sure what you mean by "I hope they don't set a fixed size buffer"

FYI, the current git head of iperf 2.0.14 hasn't undergone any windows
testing yet.  Not sure if it even compiles.  The 2.0.13 tarball is the
latest official release.

We're getting closer to a 2.0.14 release - feel free to request features.
https://youtu.be/pfzwrcTDc38

Bob

On Tue, Feb 4, 2020 at 2:28 PM Daniel Havey  wrote:

> Okay cool.  I hope they didn't set a fixed buffer size.  I will download
> iperf2 and try it out.  I'll let you know how if there are any issues.
> BTW: Do you know who is responsible for iperf3?  That's the tool that I
> have been getting limited bandwidth reports on.
>
> On Tue, Feb 4, 2020 at 2:23 PM Bob McMahon 
> wrote:
>
>> I just checked with our windows engineer and he said the iperf 2
>> <https://sourceforge.net/projects/iperf2/>team no longer uses cygwin but
>> rather builds a native version.
>>
>> Bob
>>
>> On Tue, Feb 4, 2020 at 2:07 PM Daniel Havey  wrote:
>>
>>> Hi, I'm Daniel Havey from Microsoft Windows.  I'm the PM for transports
>>> (TCP/QUIC) and there is a bug in the cygwin1.dll that was distributed with
>>> the iperf binaries.  The bug limits maximum bandwidth achievable by the
>>> iperf tool.  Details can be found in my blogpost:
>>> https://techcommunity.microsoft.com/t5/networking-blog/windows-network-performance-suffering-from-bad-buffering/ba-p/339668
>>>
>>> We worked with RedHat on Cygwin to fix the bug, but I am still getting
>>> reports of limited bandwidth from windows iperf users.  The fix is simple.
>>> Just download the new cygwin1.dll from the cygwin website and the problem
>>> will be fixed.
>>>
>>> thanks ;)
>>> ...Daniel
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf on android

[Bob McMahon via Iperf-users]

iperf 2.0.14a  is currently under
active development with multiple new features

as well as 100G support.  I haven't started the portability phase yet.  So
please don't use the latest code per git as it's not going to compile (nor
cross compile.)

One can find compiled 2.0.13 binaries for android here.
https://play.google.com/store/apps/details?id=iperf.project . The engineer
that figured out the compiling may be reachable per that.

Bob

On Tue, Dec 3, 2019 at 7:34 PM Nithya Rajagopal  wrote:

> Hi everyone,
>
> I am new to iperf. I am trying to compile the iperf on android platform.
> But I have no clue. Can anyone provide me some direction . Any sort of
> documentation or guidance is greatly appreciated.
>
> Thanks
> Nithya
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Reg. Need to test TCP incast traffic using iperf

[Bob McMahon via Iperf-users]

Speaking from an iperf 2 perspective, there are a few ways to control
server 1 and server 2 traffic start times and burst sizes in iperf 2.0.13
+

What operating systems are running on the servers?  Can you synchronize the
realtime clocks to a quality reference (e.g. a GPS disciplined OCXO
oscillator
)
using precision time protocol to synchronize the realtime clocks?

It's probably  a good idea to put a controller device running python 3.5+
in devices and run something like python flows
 code.  This
requires ssh support on the servers (and where control master
 capability is
recommended if traffic starts and stops are being done by the controller.)

Bob

On Sat, Oct 26, 2019 at 9:28 AM shaukath ali via Iperf-users <
iperf-users@lists.sourceforge.net> wrote:

> Good Morning,
>
> I need to test test ECN in my Vendor switch  with below topology :
>
>
>
> Server1 and 2 with be send   traffic over TCP session with ECN
> capability(ECT ). Once Switch finds congestion  , switch will set ECN bit
> as 11 indicating the it has experienced congestion to receiver server 3.
> Hence receiver with send info to sender to reduce the transmission rate.
>
>
> Need to test this scenario and  finding for the tool to be installed in
> servers  to send traffic over TCP session and over 10G pipeline.
>
> Need your suggesstions on this, whether this could be achieved using iperf
> or not. What are other options to achieve this.
>
> Thanks in adavance.
>
> Shaukath.
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] maximum allowed UDP bandwidth setting

[Bob McMahon via Iperf-users]

>> Consider also that the nature of iperf is to saturate the available
channel.

This isn't the case anymore for iperf 2.0.13 and greater.  Saturating the
channel has lots of negative effects with respect to testing per buffer
bloat.  2.0.13 and greater has many features to support unsaturated
channels where latency is a primary metric.

Bob

On Thu, Oct 3, 2019 at 11:26 AM Sandro Bureca  wrote:

> Try to solve this need at network level by configuring QOS or COS or
> interface speed.
> That said, flooding the network with udp packets is possible even without
> an iperf server on your side.
> Consider also that the nature of iperf is to saturate the available
> channel.
> Sandro
>
> Il gio 3 ott 2019, 13:41 van Kan, Michel (VodafoneZiggo) <
> michel.van...@vodafoneziggo.com> ha scritto:
>
>> Hi,
>>
>>
>>
>> Can a maximum allowed UDP bandwidth be set in the iperf3 server setting
>> so clients cannot use extreme values for the UDP downlink bandwidth? I like
>> to avoid that hackers can fully utilize the network bandwidth.
>>
>>
>>
>> If not what are the alternatives?
>>
>>
>>
>>
>>
>> BR,
>>
>>
>>
>> Michel
>>
>> C2 VodafoneZiggo Internal
>> ___
>> Iperf-users mailing list
>> Iperf-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] maximum allowed UDP bandwidth setting

[Bob McMahon via Iperf-users]

I can't speak for iperf 3 but iperf 2.0.13 supports -b on the server for
both TCP and UDP.  It does this by running a simplified token bucket on the
reads(). With that said, there is no way for a server to control the
transmit rate of a iperf client running UDP because UDP is connectionless.
TCP is required for an iperf server to rate limit the client's offered load
to the network.

Bob

On Thu, Oct 3, 2019 at 4:40 AM van Kan, Michel (VodafoneZiggo) <
michel.van...@vodafoneziggo.com> wrote:

> Hi,
>
>
>
> Can a maximum allowed UDP bandwidth be set in the iperf3 server setting so
> clients cannot use extreme values for the UDP downlink bandwidth? I like to
> avoid that hackers can fully utilize the network bandwidth.
>
>
>
> If not what are the alternatives?
>
>
>
>
>
> BR,
>
>
>
> Michel
>
> C2 VodafoneZiggo Internal
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Regarding the bandwidth measurements considering UDP traffic

[Bob McMahon via Iperf-users]

Iperf is an end/end measurement.  It has no idea that an AP is even in the
path.

Bob

On Fri, Sep 20, 2019 at 10:02 AM Bhanu Priya  wrote:

> Sir
> I want to know the bandwidth measured by the iperf2.0.8 considers the load
> on access point or not?. For example In a figure attached below if we are
> interested in measuring the bandwidth between server and client through
> path ABC , does iperf takes into account the load on AP1 while measuring
> the bandwidth.
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3 not working with sdn switches

[Bob McMahon via Iperf-users]

It's very difficult to debug this with such limited information  Iperf 3
does have a TCP connection before a UDP test. Iperf 2 doesn't. That's one
possibility for a UDP test issue, i.e. something is prevented the initial
TCP exchange.

Bob

On Fri, Sep 13, 2019 at 1:15 AM ha Fa  wrote:

> why iperf works with sdn switch,
> while iperf3 not working, its hangs,
> am using udp protocol
> thanks
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf 3.7 - very wide bandwidth spreading

[Bob McMahon via Iperf-users]

I think there is insufficient information here to make any meaningful
educated guesses.  Can you try with iperf 2.0.13 an use the -e option on
both the client and server?  Also, show the whole command line and describe
the test setup, interconnecting networks, and all descriptions of competing
traffic.  Also, try a 10 millisecond report interval, i.e. -i 0.01 (not
sure if iperf 3 support this.)

Bob

On Thu, Aug 8, 2019 at 9:03 AM Osdoba, Sascha  wrote:

> Dear all,
>
> i am a newbie to iperf but I see a very wide bandwidth spreading to one of
> our linux clients.
> Tested it also against some other linux and windows server the bandwidth
> is more common.
>
> iperf 3.7 (cJSON 1.5.2)
> CYGWIN_NT-10.0-14393 citpc001 3.0.7-338.x86_64 2019-04-30 18:08 UTC x86_64
>
> Done the tests one after another and there are such different values I
> could not believe the results.
>
> Windows as server and Linux & Windows as server (on linux ver 3.6 was
> used) but this not an answer because
> the other linux server was more constant..
>
> Any idea on that? If
>
>
> Replaced hostnames and IP with A & B.
>
> Log:
>
> warning: Ignoring nonsense TCP MSS 0
> Connecting to host A, port 5201
> [  5] local IP B port 55218 connected to IP A port 5201
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.00   sec  22.0 MBytes   184 Mbits/sec
> [  5]   1.00-2.00   sec  11.4 MBytes  95.5 Mbits/sec
> [  5]   2.00-3.00   sec  21.2 MBytes   178 Mbits/sec
> [  5]   3.00-4.00   sec  21.1 MBytes   177 Mbits/sec
> [  5]   4.00-5.00   sec  12.4 MBytes   104 Mbits/sec
> [  5]   5.00-6.00   sec  10.2 MBytes  86.0 Mbits/sec
> [  5]   6.00-7.00   sec  10.9 MBytes  91.2 Mbits/sec
> [  5]   7.00-8.00   sec  11.1 MBytes  93.3 Mbits/sec
> [  5]   8.00-9.00   sec  18.6 MBytes   156 Mbits/sec
> [  5]   9.00-10.00  sec  8.00 MBytes  67.1 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-10.00  sec   147 MBytes   123 Mbits/sec
> sender
> [  5]   0.00-10.05  sec   147 MBytes   123 Mbits/sec
> receiver
>
> iperf Done.
>
> --
>
> warning: Ignoring nonsense TCP MSS 0
> Connecting to host A, port 5201
> [  5] local IP B port 55225 connected to IP A port 5201
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.00   sec   114 MBytes   957 Mbits/sec
> [  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec
> [  5]   2.00-3.00   sec   112 MBytes   942 Mbits/sec
> [  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec
> [  5]   4.00-5.00   sec   112 MBytes   943 Mbits/sec
> [  5]   5.00-6.00   sec   112 MBytes   942 Mbits/sec
> [  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec
> [  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec
> [  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec
> [  5]   9.00-10.00  sec   112 MBytes   943 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-10.00  sec  1.10 GBytes   944 Mbits/sec
> sender
> [  5]   0.00-10.06  sec  1.10 GBytes   938 Mbits/sec
> receiver
>
> iperf Done.
>
> ---
>
> warning: Ignoring nonsense TCP MSS 0
> Connecting to host A, port 5201
> [  5] local IP B port 55227 connected to IP A port 5201
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-1.00   sec  2.75 MBytes  23.1 Mbits/sec
> [  5]   1.00-2.00   sec  2.88 MBytes  24.1 Mbits/sec
> [  5]   2.00-3.00   sec  17.4 MBytes   146 Mbits/sec
> [  5]   3.00-4.00   sec  10.6 MBytes  89.2 Mbits/sec
> [  5]   4.00-5.00   sec  24.5 MBytes   206 Mbits/sec
> [  5]   5.00-6.00   sec  18.9 MBytes   158 Mbits/sec
> [  5]   6.00-7.00   sec  12.6 MBytes   106 Mbits/sec
> [  5]   7.00-8.00   sec  9.75 MBytes  81.8 Mbits/sec
> [  5]   8.00-9.00   sec  18.1 MBytes   152 Mbits/sec
> [  5]   9.00-10.00  sec  18.1 MBytes   152 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate
> [  5]   0.00-10.00  sec   136 MBytes   114 Mbits/sec
> sender
> [  5]   0.00-10.05  sec   135 MBytes   113 Mbits/sec
> receiver
>
> iperf Done.
>
>
>
> Regards Sascha
>
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Dummies guide to iperf

[Bob McMahon via Iperf-users]

I think this is a very old version and will have performance problems.
Maybe try a new version,

https://sourceforge.net/projects/iperf2/files/iperf-2.0.13-win.exe/download

more links here:

https://iperf.fr/iperf-download.php#windows

Bob


On Mon, Aug 5, 2019 at 7:41 AM brent s.  wrote:

> Ashley-
>
> I use iPerf from Linux, but my understanding is the Windows version is the
> sa,e.
>
>  iPerf is a commandline program. You would need to open a cmd shell or
> PowerShell instance and run it from there.
>
> sent from my toaster.
>
> On Aug 5, 2019 08:23, Ashley Fletcher 
> wrote:
>
> Hi,
>
>
>
> Just downloaded iperf from this site, and I have no idea how to operate
> it.. how do I run the exe file? I click on it, it flashes up and then
> disappears?
>
>
>
> I need to run iperf tests ASAP, and don’t know how to get round this?
>
>
>
> Regards
>
>
>
> *Ashley Fletcher*
>
> Solutions Executive, Solutions Engineering
>
> Enterprise
>
>
>
> *Inmarsat*
>
> 99 City Road
>
> London EC1Y 1AX
>
> United Kingdom
>
>
>
> *M*   + 44 (0)7912 476 306
>
> *T *   + 44 (0)20 7728 1199
>
> *E*ashley.fletc...@inmarsat.com
>
> *W*   inmarsat.com
>
>
>
> --
>
> This communication is private and confidential and may contain information
> that is proprietary, privileged or otherwise legally exempt from
> disclosure. If you have received this message in error, please notify the
> sender immediately by e-mail and delete all copies of the message. In
> accordance with our guidelines, emails sent or received may be
> monitored.Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited,
> Registered No. 3675885. Both Registered in England and Wales with
> Registered Office at 99 City Road, London EC1Y 1AX
>
> _
> This e-mail has been scanned for viruses by Verizon Business Internet
> Managed Scanning Services - powered by MessageLabs.
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2 "short term" road map

[Bob McMahon via Iperf-users]

Hi All,

I've been doing a lot of work on iperf 2 to handle new testing features
with a focus on TCP latency testing.  Please do let me know your thoughts
or suggest comments per the list below.  No promises on time frame as this
is not my primary day job ;)

The new features currently in development to include:

o) Reverse testing (invert the client/server roles after the connect) -
requested by many for testing through NAT gateways
o) Latency tail analysis support (latency mostly needs to evaluated from a
tail's perspective, provide those metrics w/o losing full distribution or,
at least, tail information)
o) Support GPS (atomic clock) timestamps with all histogram metrics
supporting post analysis of problem areas per distributed tooling (this
assumes all tooling are synce'd to the GPS atomic clocks.)
o) TCP bidir testing support (bidirectional or full duplex traffic on the
same socket)
o) TCP write-acks - the server will ack it's reads back (w/timestamp and
byte no.) to the client per every client write(), useful for TCP streaming
class of tests and doesn't require syncs to GPS clocks
o) TCP trip times, the write() to read() latency of every clients' writes -
requires GPS clock sync - this is a one way metric
o) TCP connect only tests (run many parallel TCP connects and measure the
connect times of each) - an issue for many mobile users is that TCP connect
times are impacting user experience
o) -P support for more than 127 and now is only limited by the kernel/os
(this already fixed)
o) CPU bound warning on exit - present a warning message when an iperf test
seemed to be CPU bound vs network i/o bound
o) Mutex warn message on exit: present a warning on exit when the test
spent time on mutex locks where that may be degrading network performance
o) Teporter thread consumption rate detector to add thread delay/suspends
only when needed (currently, the code always add reporter thread delay.)
This delay can and should reduce the cores cache invalidates per cache
coherency and the use of shared memory (and its pointers) not under os
mutex protection
o) Much better debugging support per ./configure --enable-thread-debug
o) Code clean up including using function pointers to replace per pacet,
inline runtime tests (prepping to complete the C++ implementation vs
today's hybrid of C and C++)
o) Support for raw sockets to test "L2 level" performance
o) Better code encapsulation (which includes freeing of memory)

Note:  Here's an example debug that's now supported for those who want to
delve into iperf internals.

Client:
[root@localhost iperf2-code]# src/iperf -c 192.168.1.1 -i 1 -t 4
THREAD(18576):[16:28:11.702942] Thread settings copy (malloc)
from/to=0x67ac20/0x67b640
THREAD(18576):[16:28:11.703128] Thread_run_wrapper(0x67ac20 mode=2) thread
counts tot/trfc=1/1
THREAD(18576):[16:28:11.703293] Thread_run_wrapper(0x67b640 mode=4) thread
counts tot/trfc=2/1
THREAD(18577):[16:28:11.703305] Client thread started in constructor
THREAD(18578):[16:28:11.704364] Reporter thread started
THREAD(18577):[16:28:11.708777] Init settings report 0x7f2a38020fb0
THREAD(18577):[16:28:11.708839] Update connection report 0x7f2a38020fb0
winreq=0 actual=87040
THREAD(18577):[16:28:11.708853] Post report 0x7f2a38020fb0

Client connecting to 192.168.1.1, TCP port 5001
THREAD(18577):[16:28:11.708895] Init 5000 element packet ring 0x7f2a38023ee0
TCP window size: 85.0 KByte (default)

THREAD(18577):[16:28:11.708961] Init data report 0x7f2a380239a0 size 1336
using packetring 0x7f2a38023ee0
THREAD(18578):[16:28:11.709000] Remove 0x7f2a38020fb0 from reporter job
queue in rs
THREAD(18577):[16:28:11.709013] Init connection report 0x7f2a380239a0
THREAD(18578):[16:28:11.709037] Free 0x7f2a38020fb0 in rs
THREAD(18577):[16:28:11.709053] Update connection report 0x7f2a380239a0
winreq=0 actual=87040
THREAD(18577):[16:28:11.709080] Post report 0x7f2a380239a0
[  3] local 192.168.1.4 port 36276 connected with 192.168.1.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 1.0 sec  7.75 MBytes  65.0 Mbits/sec
[  3]  1.0- 2.0 sec  7.75 MBytes  65.0 Mbits/sec
[  3]  2.0- 3.0 sec  6.50 MBytes  54.5 Mbits/sec
[  3]  3.0- 4.0 sec  7.12 MBytes  59.8 Mbits/sec
[  3]  0.0- 4.0 sec  29.1 MBytes  60.5 Mbits/sec
THREAD(18578):[16:28:15.747044] Remove 0x7f2a380239a0 from reporter job
queue in rs
THREAD(18577):[16:28:15.747045] Traffic thread thinks reporter is done with
0x7f2a380239a0
THREAD(18577):[16:28:15.747098] Client destructor close sock=3
THREAD(18577):[16:28:15.747126] Free packet ring 0x7f2a38023ee0 & condition
variable await consumer 0x7f2a38023ef8
THREAD(18577):[16:28:15.747156] Free report hdr 0x7f2a380239a0 delay
counter=994
THREAD(18577):[16:28:15.747168] Thread settings free=0x67ac20
THREAD(18578):[16:28:16.000164] Thread settings free=0x67b640

Server:

[root@localhost iperf2-code]# src/iperf -s -i 1

Re: [Iperf-users] Request

[Bob McMahon via Iperf-users]

I'd start with man iperf which should have examples (if you're using iperf
2.0.13)

Bob

‪On Mon, Jun 24, 2019 at 1:53 AM ‫رغدة عبد via Iperf-users‬‎ <
iperf-users@lists.sourceforge.net> wrote:‬

> Hello everyone I want the tutorials that guide me how to use iperf tcp and
> iperf udp and how I can write the commands in the Ubuntu terminal and how I
> can save results to file and after that I plot the results,thanks
>
> Regards.
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] TCP performance Testing Question

[Bob McMahon via Iperf-users]

Well, I can speak from an iperf2 and WiFi perspective.

The main performance things to measure are speed (latency) and throughput.
 Throughput units is information over time, e.g. megabytes/second.  Speed
or latency is units time.

Most people measure throughput and think that's enough.  Network adapter
cards are usually characterized by throughput as well, i.e 1Gb/s, 10Gb/s,
etc.   But it's really not sufficient as the only metric.  Latency should
also be measured.

A "network power" metric can be better.  It is something good (throughput)
divided by something bad (slower speed.)  So it's Megabits/second squared,
hence the misnomer of "power."

Speed is a bit tricky w/TCP but RTT gives hints at it.  Note, we are
prototyping some direct TCP speed measurements.

Other things to consider include the resources required to get the
information transferred.  That's usually in memory, CPU, and energy (for
battery powered devices.)   Iperf only hints at memory with things like the
CWND.

More complex measurements deal with the shared nature of computer
networks.  How fair is it when multiple TCP streams compete?  Then with
WiFi it's more complex due to the access to the medium high costs which can
be amortized via aggregation technologies.

Then there are things like traffic classes, i.e. prioritize one over
another in speed or throughput.

There is more than this but this should get one new to performance
measurements started.

Bob

On Mon, Jun 10, 2019 at 7:40 PM Vidura Dantanarayana 
wrote:

> Hi everyone!!
> Bonjour!!
>
> I'm a beginner to performance testing and I was assigned to measure TCP
> performance between two aws ec2 machines. Can I know what kind of TCP
> related tests can be executed with iperf3? When compared perf tool and
> iperf what differences do they have in TCP performance testing. Have a nice
> day!!
>
> BR,
> Vidura Dantanarayana.
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Traffic test changing payload in virtual box

[Bob McMahon via Iperf-users]

Are you using UDP per -u?  I assume so.

What does "tcpdump arp or port "  on the client's machine show?
On my machines there will be packets even if there is no iperf server.
They'll either be ARP requests or UDP packets. Also, the output of arp -n
might be useful.  The client can write even if the ARP hasn't completed.
The local stack will drop packets until the ARP completes but this may be
dependent on things like OS flow control of the application.

If the receiver doesn't have the socket open the host OS can send a
resource/port unavailable (or equivalent) back to the client.   The client
will stop its writes() and should indicate that a write error occurred via
an error message.

Those are some of my initial thoughts.

Bob

On Mon, Jun 10, 2019 at 2:46 AM Christian Sánchez 
wrote:

> Hello,
>
> Thanks for your reply Bob.
>
> I am trying to get it working the way I have explained...the only thing is
> that my raw socket script stops running when I execute Iperf client:
> - if I run my own packet transmitter, I can send as many packets as I want
> and the raw socket script does not end, just keep waiting for more packets
> to receive (I am using the function "recvfrom")
> -when I execute Iperf, it receives one packet, and just ends almost
> immediately (like as I had done ctrl+c)
>
> Any hint on why this happens? Might it the way Iperf handles the
> connection?
>
> Cheers,
> Christian
>
> On Sat, 8 Jun 2019, 00:15 Bob McMahon,  wrote:
>
>> It sorta makes sense but not sure.   My answers are from an iperf 2
>> perspective.
>>
>> Currently, there is no way from the command line to add a header to the
>> UDP payload.  It would have to be done in source code or by something like
>> linux tc or ip tables.
>>
>> The iperf client doesn't require an iperf server for it to send packets.
>> It just needs arp to be resolved.  So a VB can receive traffic from client
>> (or transmit) only.
>>
>> Yes, I think you can get the measurements from the second computer
>> assuming the packet payload has what's expected for it to make the
>> computations.
>>
>> Bob
>>
>> On Fri, Jun 7, 2019 at 9:22 AM Christian Sánchez 
>> wrote:
>>
>>> Hi,
>>> Probably the topic is not very helpful...Let me explain my situation in
>>> more detail: I need to modify the UDP payload generated by Iperf, so I can
>>> add an additional header to it. My idea is to run an Iperf client in a
>>> computer, and use this client to send traffic to a virtual box in the same
>>> computer. In the virtual box I would be running a script using a raw socket
>>> to receive the data. After receiving it, and adding the header, I send it
>>> to another Iperf server (in another computer), which would receive the data
>>> after having removed the header.
>>> My questions:
>>> I don't have a clear understanding of the working details of Iperf, does
>>> what I have explained above make sense at all to you?
>>> Can I expect to get traffic in the VB from the client even when I'm not
>>> running any server in the VB?
>>> If by any chance I finally get traffic in the second computer, can I
>>> expect it to perform correct measures from the traffic generated by the
>>> client?
>>>
>>> Cheers
>>> Christian
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Traffic test changing payload in virtual box

[Bob McMahon via Iperf-users]

It sorta makes sense but not sure.   My answers are from an iperf 2
perspective.

Currently, there is no way from the command line to add a header to the UDP
payload.  It would have to be done in source code or by something like
linux tc or ip tables.

The iperf client doesn't require an iperf server for it to send packets.
It just needs arp to be resolved.  So a VB can receive traffic from client
(or transmit) only.

Yes, I think you can get the measurements from the second computer assuming
the packet payload has what's expected for it to make the computations.

Bob

On Fri, Jun 7, 2019 at 9:22 AM Christian Sánchez 
wrote:

> Hi,
> Probably the topic is not very helpful...Let me explain my situation in
> more detail: I need to modify the UDP payload generated by Iperf, so I can
> add an additional header to it. My idea is to run an Iperf client in a
> computer, and use this client to send traffic to a virtual box in the same
> computer. In the virtual box I would be running a script using a raw socket
> to receive the data. After receiving it, and adding the header, I send it
> to another Iperf server (in another computer), which would receive the data
> after having removed the header.
> My questions:
> I don't have a clear understanding of the working details of Iperf, does
> what I have explained above make sense at all to you?
> Can I expect to get traffic in the VB from the client even when I'm not
> running any server in the VB?
> If by any chance I finally get traffic in the second computer, can I
> expect it to perform correct measures from the traffic generated by the
> client?
>
> Cheers
> Christian
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Throughput Testing of 100G Capacity using iPerf

[Bob McMahon via Iperf-users]

Thanks.  I'm curious to how much the threading helps performance here if at
all.   That part of the design we inherited from iperf 2 when we took over
maintenance of it.  We tried to keep the overall code similar in order to
not impact performance.   At first we tried not to touch the traffic
threads "fast paths" but over time found we really needed to.  We also kept
the output the same for script compatibility.   For newer enhanced output,
the -e flag is required.

We're considering adding CPU measurements but probably not directly rather
via coordination using the python controller model.  Another possibility is
a hotelling multivariate statistic to monitor CPU, memory, latency and
average throughput - but that's all for regression detections and probably
only of interest to automated test houses.

Do let me know if you are able to get some data.   We have access to WiFi
class devices and platforms and some 10G but no machines that support 100G.

Bob



On Thu, May 30, 2019 at 12:41 PM Jeffrey Lane  wrote:

> On Thu, May 30, 2019 at 3:23 PM Bob McMahon 
> wrote:
> >
> > hmm, I confused.  Did you run multiple iperf 3 sessions or iperf 2 with
> the -P 8,10 option or possibly both?  Your previous response said the only
> way to get this was with multiple iperf 3 sessions and didn't mention iperf
> 2 nor the use of -P.
>
> multiple iperf3 instances, similar to what Chris Preimesberger
> demonstrates in his video, only we use upwards of 10 threads. (it
> works out to about 1 thread per 10Gb of bandwidth).
>
> You mentioned iperf2 would be interesting to try, I was just
> commenting that we went with multiple iperf3 instances vs a single
> "iperf2 -P" because iperf3 does some things we wanted (like CPU
> measurements) but lacks true multithreading.  The "use multiple
> instances of iperf3" is a workaround to lack of proper
> multi-threading.  Also, note, I'm not an expert, we came to this by
> way of a lot of internet reading and trial and error.
>
> > In theory, iperf 2 could outperform iperf 3 per the use of threads, e..g
> separating the traffic from the accounting and reporting.  I'm curious to
> actual experimental results.
> > Note:  Iperf 2.0.13 is really required for this class of testing as
> older iperf  versions (e.g. 2.0.5) have performance related bugs.
>
> It may.  If one of my machines frees up I may try this to see how it
> works out. No promises though, I've already got too much work as it is
> :(
>
> >
> > Bob
> >
> > On Thu, May 30, 2019 at 11:49 AM Jeffrey Lane 
> wrote:
> >>
> >> For my needs (very simple testing) yes. We had to do that because
> >> iperf3 doesn't multi-thread like iperf 2 did, unfortunately.
> >>
> >> On Thu, May 30, 2019 at 1:37 PM Bob McMahon 
> wrote:
> >> >
> >> > Is it just multiple threads?  It might be interesting to try iperf
> 2.0.13 and the -P 8 option.
> >> >
> >> > Bob
> >> >
> >> > On Thu, May 30, 2019 at 10:04 AM Jeffrey Lane 
> wrote:
> >> >>
> >> >> I've been working on this a bit and the only way to get it was to run
> >> >> multiple iperf3 threads. To do this, you have to set up several (we
> do
> >> >> about 8 threads for 100Gb, possibly 10) on the target (listening to
> >> >> different ports) and then run to client instances (one for each
> port),
> >> >> then aggregate the results for each, and that nets in the 92-97Gb/s
> >> >> range overall.
> >> >>
> >> >> Additionally, in some cases tweaks are necessary (jumbo frames, some
> >> >> kernel tweaks, driver tweaks, etc) but that's all case-by-case.
> >> >>
> >> >> And it is very much constrained by CPU and PCIe bandwidth.
> >> >>
> >> >>
> >> >> On Thu, May 30, 2019 at 12:38 PM Chris Preimesberger <
> ccpi...@gmail.com> wrote:
> >> >> >
> >> >> > I tried and got up to 87Gbps throughput.  The results were CPU
> bound.  I want to build new i7 9900K PCs and re-test.  Here's a video of my
> attempt:
> >> >> >
> >> >> > https://youtu.be/uh2zvaaH0hc
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, May 30, 2019, 3:08 AM Ashwajit Bhoutkar <
> bhout...@gmail.com> wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> Just wanted to check whether it is possible to test the
> throughput of 100G link using iPerf.
> >> >> >>
> &g

Re: [Iperf-users] Throughput Testing of 100G Capacity using iPerf

[Bob McMahon via Iperf-users]

hmm, I confused.  Did you run multiple iperf 3 sessions or iperf 2 with the
-P 8,10 option or possibly both?  Your previous response said the only way
to get this was with multiple iperf 3 sessions and didn't mention iperf 2
nor the use of -P.

In theory, iperf 2 could outperform iperf 3 per the use of threads, e..g
separating the traffic from the accounting and reporting.  I'm curious to
actual experimental results.

Note:  Iperf 2.0.13 is really required for this class of testing as older
iperf  versions (e.g. 2.0.5) have performance related bugs.

Bob

On Thu, May 30, 2019 at 11:49 AM Jeffrey Lane  wrote:

> For my needs (very simple testing) yes. We had to do that because
> iperf3 doesn't multi-thread like iperf 2 did, unfortunately.
>
> On Thu, May 30, 2019 at 1:37 PM Bob McMahon 
> wrote:
> >
> > Is it just multiple threads?  It might be interesting to try iperf
> 2.0.13 and the -P 8 option.
> >
> > Bob
> >
> > On Thu, May 30, 2019 at 10:04 AM Jeffrey Lane 
> wrote:
> >>
> >> I've been working on this a bit and the only way to get it was to run
> >> multiple iperf3 threads. To do this, you have to set up several (we do
> >> about 8 threads for 100Gb, possibly 10) on the target (listening to
> >> different ports) and then run to client instances (one for each port),
> >> then aggregate the results for each, and that nets in the 92-97Gb/s
> >> range overall.
> >>
> >> Additionally, in some cases tweaks are necessary (jumbo frames, some
> >> kernel tweaks, driver tweaks, etc) but that's all case-by-case.
> >>
> >> And it is very much constrained by CPU and PCIe bandwidth.
> >>
> >>
> >> On Thu, May 30, 2019 at 12:38 PM Chris Preimesberger 
> wrote:
> >> >
> >> > I tried and got up to 87Gbps throughput.  The results were CPU
> bound.  I want to build new i7 9900K PCs and re-test.  Here's a video of my
> attempt:
> >> >
> >> > https://youtu.be/uh2zvaaH0hc
> >> >
> >> >
> >> >
> >> > On Thu, May 30, 2019, 3:08 AM Ashwajit Bhoutkar 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Just wanted to check whether it is possible to test the throughput
> of 100G link using iPerf.
> >> >>
> >> >>
> >> >> Thank You,
> >> >>
> >> >> Kind Regards,
> >> >> Ashwajit
> >> >> ___
> >> >> Iperf-users mailing list
> >> >> Iperf-users@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/iperf-users
> >> >
> >> > ___
> >> > Iperf-users mailing list
> >> > Iperf-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/iperf-users
> >>
> >>
> >>
> >> --
> >> Jeff Lane
> >> Engineering Manager
> >> IHV/OEM Alliances and Server Certification
> >>
> >> "Entropy isn't what it used to be."
> >>
> >>
> >> ___
> >> Iperf-users mailing list
> >> Iperf-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
>
> --
> Jeff Lane
> Engineering Manager
> IHV/OEM Alliances and Server Certification
>
> "Entropy isn't what it used to be."
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Throughput Testing of 100G Capacity using iPerf

[Bob McMahon via Iperf-users]

Is it just multiple threads?  It might be interesting to try iperf 2.0.13
and the -P 8 option.

Bob

On Thu, May 30, 2019 at 10:04 AM Jeffrey Lane  wrote:

> I've been working on this a bit and the only way to get it was to run
> multiple iperf3 threads. To do this, you have to set up several (we do
> about 8 threads for 100Gb, possibly 10) on the target (listening to
> different ports) and then run to client instances (one for each port),
> then aggregate the results for each, and that nets in the 92-97Gb/s
> range overall.
>
> Additionally, in some cases tweaks are necessary (jumbo frames, some
> kernel tweaks, driver tweaks, etc) but that's all case-by-case.
>
> And it is very much constrained by CPU and PCIe bandwidth.
>
>
> On Thu, May 30, 2019 at 12:38 PM Chris Preimesberger 
> wrote:
> >
> > I tried and got up to 87Gbps throughput.  The results were CPU bound.  I
> want to build new i7 9900K PCs and re-test.  Here's a video of my attempt:
> >
> > https://youtu.be/uh2zvaaH0hc
> >
> >
> >
> > On Thu, May 30, 2019, 3:08 AM Ashwajit Bhoutkar 
> wrote:
> >>
> >> Hi,
> >>
> >> Just wanted to check whether it is possible to test the throughput of
> 100G link using iPerf.
> >>
> >>
> >> Thank You,
> >>
> >> Kind Regards,
> >> Ashwajit
> >> ___
> >> Iperf-users mailing list
> >> Iperf-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/iperf-users
> >
> > ___
> > Iperf-users mailing list
> > Iperf-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
>
> --
> Jeff Lane
> Engineering Manager
> IHV/OEM Alliances and Server Certification
>
> "Entropy isn't what it used to be."
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Throughput Testing of 100G Capacity using iPerf

[Bob McMahon via Iperf-users]

Can you run with iperf 2.0.13
 using the same setup?
 I'd be curious to see how it performs compared to iperf 3.  If you're able
try this, please use the --realtime option to see if that helps.

Bob

On Thu, May 30, 2019 at 9:38 AM Chris Preimesberger 
wrote:

> I tried and got up to 87Gbps throughput.  The results were CPU bound.  I
> want to build new i7 9900K PCs and re-test.  Here's a video of my attempt:
>
> https://youtu.be/uh2zvaaH0hc
>
>
>
> On Thu, May 30, 2019, 3:08 AM Ashwajit Bhoutkar 
> wrote:
>
>> Hi,
>>
>> Just wanted to check whether it is possible to test the throughput of
>> 100G link using iPerf.
>>
>>
>> Thank You,
>>
>> Kind Regards,
>> Ashwajit
>> ___
>> Iperf-users mailing list
>> Iperf-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Throughput Testing of 100G Capacity using iPerf

[Bob McMahon via Iperf-users]

I think it will be CPU constrained by the computer CPU and difficult to
accomplish with one iperf stream.  Also, you may want to qualify in terms
of packets per second as that's likely the bottleneck.

Iperf 2 has some experimental python 3 code in the flows directory that can
coordinate multiple traffic flows over multiple computers.  It assumes ssh
access from the python controller.

Iperf 3 is targeting high speed research networks and may be a better
option - not sure.

Bob

On Thu, May 30, 2019, 1:08 AM Ashwajit Bhoutkar  wrote:

> Hi,
>
> Just wanted to check whether it is possible to test the throughput of 100G
> link using iPerf.
>
>
> Thank You,
>
> Kind Regards,
> Ashwajit
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Framesize

[Bob McMahon via Iperf-users]

For UDP (-u) the -l on the client defines the UDP payload size.  A 1470
byte UDP payload will generate the max ethernet frame for ipv4 and 1450
bytes for ipv6.

TCP is a byte protocol where there is no direct control of a layer 2
packet's frame size.   The -l sets the write() size, -w the window size, -M
the maximum segment size and the MTU size is set on an interface per the
operating system.

Bob

On Wed, May 29, 2019 at 8:55 AM Sudeep Gupta 
wrote:

> Hi,
>
> I want to run a test using a fixed framesize. I couldn't find an option to
> set the framesize in iperf documentation. Can someone point me to the
> parameter which can specify framesize?
>
> Regards,
> Sudeep
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2.0.13 released today

[Bob McMahon via Iperf-users]

FYI, iperf 2.0.13 is released on sourceforge
https://sourceforge.net/projects/iperf2/  We've done a lot of testing with
this version and added some new features.   Information about it can be
found on sourceforge.

Bob
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Calculating E2E delay and overhead from iperf results

[Bob McMahon via Iperf-users]

I don't think iperf3 supports this.   I think you'll need to use iperf2.

Bob

On Fri, Jan 18, 2019 at 12:04 AM karima smida 
wrote:

> Hi Bob,
> First, thank you for your reply. Please, as I m a beginner, can you help
> me with a solution with iperf3 and Synchronisation with NTP, a tutorial or
> a video... Thank you in advance.
>
> karima.
>
> Le mer. 16 janv. 2019 19:24, Bob McMahon  a
> écrit :
>
>> Hi Karima,
>>
>> For iperf 2 <https://sourceforge.net/projects/iperf2/>use the -e
>> option.  This assumes the clocks on the client and server are synchronized
>> to a level of the precision one cares about.  We use a GPS disciplined oven
>> controlled oscillator in our labs for a high quality reference then use
>> precision time protocol to distributes that clock.
>>
>> o) 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 to an OCXO oscillator per Spectracom)
>>
>> There is also support for full histograms vs mean/min/max/standard
>> deviation.
>>
>> o) Latency histograms for both packets and frames (e.g.
>> --udp-histogram=10u,20, 0.03, 99.97)
>>
>> More on enhanced features here
>> <https://sourceforge.net/projects/iperf2/files/Iperf%202.0.13a%20Enhancements.pdf/download>
>> .
>>
>> Also, suggested use the latest 2.013a from sourceforge.  We're very close
>> to releasing 2.0.13
>>
>> Bob
>>
>> On Wed, Jan 16, 2019 at 3:11 AM karima smida 
>> wrote:
>>
>>> Hi all,
>>> please how to calculate End to End delay from informations returned by
>>> iperf?
>>> In fact, I want to use iperf to inject UDP traffic in may SDN network to
>>> test its performance in terms of  delay and overhead.
>>> Thank you for help.
>>>
>>> --
>>>
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Calculating E2E delay and overhead from iperf results

[Bob McMahon via Iperf-users]

Hi Karima,

For iperf 2 use the -e option.
This assumes the clocks on the client and server are synchronized to a
level of the precision one cares about.  We use a GPS disciplined oven
controlled oscillator in our labs for a high quality reference then use
precision time protocol to distributes that clock.

o) 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
to an OCXO oscillator per Spectracom)

There is also support for full histograms vs mean/min/max/standard
deviation.

o) Latency histograms for both packets and frames (e.g.
--udp-histogram=10u,20, 0.03, 99.97)

More on enhanced features here

.

Also, suggested use the latest 2.013a from sourceforge.  We're very close
to releasing 2.0.13

Bob

On Wed, Jan 16, 2019 at 3:11 AM karima smida  wrote:

> Hi all,
> please how to calculate End to End delay from informations returned by
> iperf?
> In fact, I want to use iperf to inject UDP traffic in may SDN network to
> test its performance in terms of  delay and overhead.
> Thank you for help.
>
> --
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Consulta

[Bob McMahon via Iperf-users]

Speaking from an iperf 2 perspective, the systems generating and syncing
traffic need to be considered.   We qualify the computers we use to act as
iperf traffic generators.  It also depends on the operating systems as
well.   It also depends upon the capacity of the links under test.

Bob

On Wed, Dec 19, 2018 at 9:31 AM Ilia Alexis Mejias Ortiz <
ilia.mejia...@movistar.cl> wrote:

> Dear,
>
>
>
> I have a question, the computers in which they carry out the tests, do
> they influence the results? that is, the capacity of RAM and / or CPU.
>
>
>
> Ilia Alexis Mejias Ortiz
>
> Ing. En Conectividad y Redes
>
> Celular + 56 9 6171 8469
>
>
>
>
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] UDP and QoS tests in Iperf3

[Bob McMahon via Iperf-users]

Just an FYI, comparing a VO with 1 mpdu per ampdu vs 32 and small packets
(minimize airtime.)  If VO can break 10K pps it's most likely aggregating.

[root@localhost iperf2-code]# wl -i ap0 ampdu_mpdu 1
root@localhost iperf2-code]# iperf -c 192.168.1.4 -u -S 0xC0 -b 40m -e -i 1
-t 10 -l 20

Client connecting to 192.168.1.4, UDP port 5001 with pid 16463
Sending 20 byte datagrams, IPG target: 4.00 us (kalman adjust)
UDP buffer size:  208 KByte (default)

[  3] local 192.168.1.1 port 41010 connected with 192.168.1.4 port 5001
[ ID] IntervalTransfer Bandwidth  Write/Err  PPS
[  3] 0.-1. sec   161 KBytes  1.32 Mbits/sec  8243/0 8167 pps
[  3] 1.-2. sec   158 KBytes  1.29 Mbits/sec  8085/0 8035 pps
[  3] 2.-3. sec   155 KBytes  1.27 Mbits/sec  7928/0 8040 pps
[  3] 3.-4. sec   158 KBytes  1.29 Mbits/sec  8075/0 8035 pps
[  3] 4.-5. sec   158 KBytes  1.30 Mbits/sec  8094/0 8019 pps
[  3] 5.-6. sec   155 KBytes  1.27 Mbits/sec  7954/0 8032 pps
[  3] 6.-7. sec   158 KBytes  1.30 Mbits/sec  8097/0 8040 pps
[  3] 7.-8. sec   155 KBytes  1.27 Mbits/sec  7930/0 8034 pps
[  3] 8.-9. sec   158 KBytes  1.30 Mbits/sec  8095/0 8034 pps
[  3] 0.-10.0153 sec  1.54 MBytes  1.29 Mbits/sec  80596/0 8047 pps
[  3] Sent 80596 datagrams
[  3] Server Report:
[  3] 0.-10.0293 sec  1.54 MBytes  1.29 Mbits/sec   1.179 ms0/80596
(0%) 26.031/ 0.709/36.593/ 0.197 ms 8036 pps  6.17

[root@localhost iperf2-code]# wl -i ap0 ampdu_mpdu 32
[root@localhost iperf2-code]# iperf -c 192.168.1.4 -u -S 0xC0 -b 40m -e -i
1 -t 10 -l 20

Client connecting to 192.168.1.4, UDP port 5001 with pid 16467
Sending 20 byte datagrams, IPG target: 4.00 us (kalman adjust)
UDP buffer size:  208 KByte (default)

[  3] local 192.168.1.1 port 58139 connected with 192.168.1.4 port 5001
[ ID] IntervalTransfer Bandwidth  Write/Err  PPS
[  3] 0.-1. sec   797 KBytes  6.53 Mbits/sec  40826/040801 pps
[  3] 1.-2. sec   796 KBytes  6.52 Mbits/sec  40737/040727 pps
[  3] 2.-3. sec   794 KBytes  6.50 Mbits/sec  40652/040685 pps
[  3] 3.-4. sec   797 KBytes  6.53 Mbits/sec  40815/040708 pps
[  3] 4.-5. sec   793 KBytes  6.50 Mbits/sec  40613/040656 pps
[  3] 5.-6. sec   794 KBytes  6.51 Mbits/sec  40663/040692 pps
[  3] 6.-7. sec   796 KBytes  6.52 Mbits/sec  40779/040722 pps
[  3] 7.-8. sec   793 KBytes  6.50 Mbits/sec  40624/040704 pps
[  3] 8.-9. sec   797 KBytes  6.53 Mbits/sec  40813/040713 pps
[  3] 0.-10.0018 sec  7.77 MBytes  6.51 Mbits/sec  407178/040710 pps
[  3] Sent 407178 datagrams
[  3] Server Report:
[  3] 0.-10.0022 sec  7.77 MBytes  6.51 Mbits/sec   0.276 ms
0/407178 (0%)  5.159/ 1.293/ 8.469/ 0.091 ms 40708 pps  157.82

Bob

On Tue, Nov 20, 2018 at 11:26 AM Bob McMahon 
wrote:

> VO AC may not use ampdu aggregation so double check that.  The reason is
> that VO are small packet payloads (~200 bytes) and have low relative
> frequency of transmits.   A wireless driver waiting around to fill an AMPDU
> from a VO queue will cause excessive latency and impact the voice session.
>  Many drivers won't aggregate them.Since VO isn't likely using ampdus
> and since it has the most preferred wme access settings, a 40 Mb/s iperf
> flow with VO is going to consume most all the TXOPs.  The other access
> classes won't have many TXOPS at all. (The whole point of WiFi aggregation
> technologies is to amortize the media access cost which is expensive per
> collision avoidance.  A rough theoretical max estimate for TXOPs is 10,000
> per second.)   Maybe measure the packets per second of just VO to get an
> empirical number.  It's probably better to reduce this to something more
> typical of lets say 10 voice calls (or 20 call legs.)
>
> You might also want to consider measuring "network power" which, while a
> bit of a misnomer, is defined as average throughput over delay.Also,
> maybe consider changing AIFS too.  This can lead to interesting things.
> Not sure you're exact goals but just some other things to consider.
>
> Bob
>
> On Tue, Nov 20, 2018 at 9:08 AM Kasper Biegun  wrote:
>
>> Hi Bruce,
>>
>> I am making a thesis project and I have to measure influence of a-mpdu
>> and TXOPlimit on the 802.11ac network efficiency and I have to obtain
>> plot of BK, BE, VI and VO throughputs, when they are running at the same
>> time. I have to measure some scenarios with different ampdu sizes and
>> when TXOPlimit is enabled and disabled.
&

Re: [Iperf-users] UDP and QoS tests in Iperf3

[Bob McMahon via Iperf-users]

VO AC may not use ampdu aggregation so double check that.  The reason is
that VO are small packet payloads (~200 bytes) and have low relative
frequency of transmits.   A wireless driver waiting around to fill an AMPDU
from a VO queue will cause excessive latency and impact the voice session.
 Many drivers won't aggregate them.Since VO isn't likely using ampdus
and since it has the most preferred wme access settings, a 40 Mb/s iperf
flow with VO is going to consume most all the TXOPs.  The other access
classes won't have many TXOPS at all. (The whole point of WiFi aggregation
technologies is to amortize the media access cost which is expensive per
collision avoidance.  A rough theoretical max estimate for TXOPs is 10,000
per second.)   Maybe measure the packets per second of just VO to get an
empirical number.  It's probably better to reduce this to something more
typical of lets say 10 voice calls (or 20 call legs.)

You might also want to consider measuring "network power" which, while a
bit of a misnomer, is defined as average throughput over delay.Also,
maybe consider changing AIFS too.  This can lead to interesting things.
Not sure you're exact goals but just some other things to consider.

Bob

On Tue, Nov 20, 2018 at 9:08 AM Kasper Biegun  wrote:

> Hi Bruce,
>
> I am making a thesis project and I have to measure influence of a-mpdu
> and TXOPlimit on the 802.11ac network efficiency and I have to obtain
> plot of BK, BE, VI and VO throughputs, when they are running at the same
> time. I have to measure some scenarios with different ampdu sizes and
> when TXOPlimit is enabled and disabled.
>
> Thank you very much for your help, thanks to you I was able to run the
> tests, but I am still having some troubles.
>
> Today I have tried running tests again, but with lower iperf bandwidth
> (and window parameter) and it worked better, because I was able to run
> all four tests at the same time. But I had troubles with the highest
> priority traffic VO - it "takes" whole bandwidth. I mean that when I set
> e.g bandwidth (-b) to 40Mbits, VO traffic takes 40Mbits (the rest
> 20Mbits is divided to the rest of traffics) and it is undesirable during
> my measurements, because it is like manual limitation than network
> limitation.
>
>
> Example command:
>
> #iperf3 -c 10.10.0.1 -p 5025 -b 40M -u -S 0xc0 -i 1 -w 8192B --bind
> 10.10.0.2 --cport 5023
>
>
> Kasper
>
>
> W dniu 2018-11-20 o 00:24, Bruce A. Mah pisze:
> > If memory serves me right, Kasper Biegun wrote:
> >
> >> to connect server and client I am using WiFi 5GHz (802.11ac), band:
> >> 20MHz with MCS (7 or 8) so I can get 65 to 78 Mbit/s. When I am testing
> >> now, I get around 60Mbit/s for the first test and after that second test
> >> starts and reaches around 60Mbit/s. But according to my assumptions it
> >> should work at the same time and divide possible bandwidth (I set values
> >> of TXOPlimit according to 802.11ac standard).
> > Hi Kasper--
> >
> > I'm not sure why the tests are serialized.  The only thing I can think
> > of is that the first test has completely blocked the wireless link so
> > that the second test can't even start.
> >
> > Wait.  You're testing over wireless?  Yet you're doing 1000Mbps = 1Gbps
> > tests.  I don't think there's any wireless link that can handle two
> > 1Gbps tests, or even one.  I think you really are saturating the link.
> > Because the tests are using UDP they'll just blast out packets at
> > whatever rate you specify regardless of whether the path is actually
> > capable of supporting it.  You need to turn down the bitrate on both
> > tests (especially the first).  What scenario are you trying to simulate
> > anyway?
> >
> > Bruce.
> >
> >> W dniu 2018-11-19 o 21:50, Bruce A. Mah pisze:
> >>
> >>> If memory serves me right, Kasper Biegun wrote:
> >>>
>  currently I'm working on project connected with testing UDP throughput
>  for different QoS values. To get the needed results I have to use Best
>  Effort (0x70), Background (0x28), Voice (0xc0) and Video (0xb8)
> traffic
>  at the same time. I have troubles with running them, because one
> stream
>  was waiting for another to finish or if they started - only one was
>  working (the rest had 0 bandwidth). Then I updated iperf to newest
>  version available on github and installed it. Now, for testing
> purposes,
>  I am running only Voice and Video at the same time, and I am still
>  getting the same issue - one transfer is waiting for the second one to
>  finish.
> 
>  I am using commands:
> 
>    - on server: #iperf3 -s -p 5015 and #iperf -s -p 5020
> 
>    - on transmitter: #iperf3 -c 10.10.0.1 -p 5015 -S 192 --bind
>  10.10.0.2 --cport 5013 -u -b 1000m and
> 
>    #iperf3 -c 10.10.0.1 -p 5020 -S 184 --bind 10.10.0.2 --cport
>  5018 -u -b 1000m
> 
>  Server is working on Ubuntu 16.04 and transmitter is on Raspberry Pi
> 3.
> 
> 
>  

Re: [Iperf-users] Iperf on Cisco Router/Switch

[Bob McMahon via Iperf-users]

Also, consider that iperf is a CPU based traffic system.  I'm doubtful any
of the router/switch CPUs could compete with modern server class systems.
 It may be better to connect 10G links to the switch/router and source
traffic externally vs burden an router/switch CPU with this.

For multiple traffic flows, one can use -P and/or the flows python code
.  There are
other tools as well including flent  though I think
that mostly uses netperf.

Bob

On Tue, Oct 23, 2018 at 2:20 PM Andrew Bosch  wrote:

> Probably not for Cisco switches and routers that run IOS or CatOS since
> those are closed systems. The ones that run IOS-XR or NX-OS maybe, since
> those have a Linux kernel.
>
>
>
>
>
> *From:* Ashwajit Bhoutkar 
> *Sent:* Tuesday, October 23, 2018 11:46 AM
> *To:* iperf-users@lists.sourceforge.net
> *Subject:* [Iperf-users] Iperf on Cisco Router/Switch
>
>
>
> Hi,
>
>
>
> Is it possible to install iPerf on a Cisco Router and Switch. If, yes, can
> you please let me know the process for the same.
>
>
>
>
>
> Thank You
>
>
>
> Kind Regards,
>
> Ashwajit
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Iperf on Cisco Router/Switch

[Bob McMahon via Iperf-users]

This is probably a question for Cisco and they would probably need to know
which switch or router model.  We don't see Cisco personnel on this list.

Bob

On Tue, Oct 23, 2018 at 9:48 AM Ashwajit Bhoutkar 
wrote:

> Hi,
>
> Is it possible to install iPerf on a Cisco Router and Switch. If, yes, can
> you please let me know the process for the same.
>
>
> Thank You
>
> Kind Regards,
> Ashwajit
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3 UDP not working with iptables drop random?

[Bob McMahon via Iperf-users]

Can you share the iperf 2.0.13a 
output?

Bob

On Fri, Aug 17, 2018 at 1:07 PM, Hector Azpurua  wrote:

> Hi guys,
>
> I'm performing some local test on my network with iperf3 using UDP
> connections between 2 Ubuntu 18.04 hosts. But it seems that the UDP iperf3
> connections it is not robust to support a random packet drop of 0.1? When
> executing the iperf3 tests, the server hangs (i need to restart the server
> to allow connecting again) and I'm seeing this errors:
>
> At the server:
>
> *iperf3: the client has unexpectedly closed the connection*
>
> At the client:
>
> *error - unable to write to stream socket: Operation not permitted*
>
> To simulate/test a bad hop on my network I'm using iptables to generate
> random packet drops with this command (executed at the host A):
>
>
> *sudo iptables -A OUTPUT -p udp -d HOSTB -m statistic --mode random
> --probability 0.01 -j DROP*
> And the iperf3 client executed at the host A:
>
> *iperf3 --version4 --udp --client 10.0.3.10 --port 4000 --bind 10.0.1.10
> --cport 12346 --json --zerocopy --verbose --bandwidth 300M --debug*
>
> At the host B i'm using:
>
> *iperf3 --verbose --server --port 4000 --version4 --debug*
>
> As far as documentation/internet examples goes, iperf3 can work with very
> bad networks, what can be happening here?
>
> I have posted this question on ServerFault also: https://serverfault.com/
> questions/926900/iperf3-udp-not-reliable-with-iptables-drop-random. My
> iperf3 version is:
>
> *iperf 3.1.3*
> *Linux PC1 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC 2018
> x86_64*
> *Optional features available: CPU affinity setting, IPv6 flow label, TCP
> congestion algorithm setting, sendfile / zerocopy, socket pacing*
>
> The problem also happens with iperf2.
>
> Thanks!
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] How does iperf UDP test count lost packets?

[Bob McMahon via Iperf-users]

speaking for iperf2 , the iperf
client writes a sequence number in every packet.   The server then
calculates the lost packets per the sequence number gaps.

For iperf2, there is no test hanshake between client and server for basic
UDP tests.

Bob

On Mon, Aug 6, 2018 at 12:53 AM, Ayrton Senna 
wrote:

> Hello,
>
> This question has been bugging me since I started using iperf and I
> couldn't find an answer by simply sifting through old iperf discussions
> online.
>
> So, Since UDP uses connectionless communication, how, in theory, is iperf
> using it to know the number of lost packets during transmission between
> service and client?
> I can only imagine that this is achieved by establishing a TCP(or
> other)-based connection on top first, and then somehow wrapping the UDP
> connection, because when iperf UDP test is run, both client and server seem
> to exchange information or do some sort of handshaking.
>
> Thanks,
> Ayrton
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] Google's BBR

[Bob McMahon via Iperf-users]

Below are two runs over wired GigE comparing Google's BBR
 with cubic.  Note, for the
network power the delay units are microseconds while the throughput are
seconds.

*A cubic run, netpower of 53532*

[root@rjm-clubhouse-28 iperf2-code]# uname -r
4.17.9-200.fc28.x86_64
[root@rjm-clubhouse-28 iperf2-code]# echo "cubic" > /proc/sys/net/ipv4/tcp_
congestion_control
[root@rjm-clubhouse-28 iperf2-code]# iperf -c 192.168.100.33 -e -i 1

Client connecting to 192.168.100.33, TCP port 5001 with pid 17263
Write buffer size:  128 KByte
TCP window size: 85.0 KByte (default)

[  3] local 192.168.100.10 port 56218 connected with 192.168.100.33 port
5001
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
 Cwnd/RTTNetPwr
[  3] 0.00-1.00 sec   113 MBytes   947 Mbits/sec  903/0  0
373K/2231 us  53051.55
[  3] 1.00-2.00 sec   112 MBytes   937 Mbits/sec  894/0  0
373K/2107 us  55613.84
[  3] 2.00-3.00 sec   112 MBytes   937 Mbits/sec  894/0  0
373K/2205 us  53142.12
[  3] 3.00-4.00 sec   112 MBytes   938 Mbits/sec  895/0  0
373K/2194 us  53468.30
[  3] 4.00-5.00 sec   111 MBytes   932 Mbits/sec  889/0  0
373K/2181 us  53426.41
[  3] 5.00-6.00 sec   112 MBytes   940 Mbits/sec  896/0  0
373K/2221 us  52877.31
[  3] 6.00-7.00 sec   112 MBytes   940 Mbits/sec  896/0  0
373K/2198 us  53430.62
[  3] 7.00-8.00 sec   111 MBytes   933 Mbits/sec  890/0  0
373K/2203 us  52952.37
[  3] 8.00-9.00 sec   111 MBytes   934 Mbits/sec  891/0  0
373K/2169 us  53842.85
[  3] 9.00-10.00 sec   112 MBytes   941 Mbits/sec  897/0  0
373K/2187 us  53759.30
[  3] 0.00-10.01 sec  1.09 GBytes   937 Mbits/sec  8945/0  0
373K/2189 us  53532.01


*A  run with BBR, netpower 72071*
[root@rjm-clubhouse-28 iperf2-code]# iperf -c 192.168.100.33 -e -i 1

Client connecting to 192.168.100.33, TCP port 5001 with pid 18312
Write buffer size:  128 KByte
TCP window size:  128 KByte (default)

[  3] local 192.168.100.10 port 56238 connected with 192.168.100.33 port
5001
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
 Cwnd/RTTNetPwr
[  3] 0.00-1.00 sec   114 MBytes   956 Mbits/sec  912/0  0
274K/1644 us  72711.47
[  3] 1.00-2.00 sec   111 MBytes   933 Mbits/sec  890/0  0
271K/1619 us  72053.17
[  3] 2.00-3.00 sec   112 MBytes   937 Mbits/sec  894/0  0
274K/1720 us  68126.96
[  3] 3.00-4.00 sec   112 MBytes   938 Mbits/sec  895/0  0
271K/1599 us  73364.25
[  3] 4.00-5.00 sec   112 MBytes   938 Mbits/sec  895/0  0
274K/1603 us  73181.19
[  3] 5.00-6.00 sec   111 MBytes   930 Mbits/sec  887/0  0
271K/1609 us  72256.60
[  3] 6.00-7.00 sec   112 MBytes   940 Mbits/sec  896/0  0
274K/1579 us  74376.51
[  3] 7.00-8.00 sec   112 MBytes   937 Mbits/sec  894/0  0
274K/1615 us  72556.27
[  3] 8.00-9.00 sec   112 MBytes   935 Mbits/sec  892/0  0
274K/1646 us  71030.51
^C[  3] 0.00-9.49 sec  1.04 GBytes   938 Mbits/sec  8489/0  0
271K/1627 us  72071.69

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] Netpower stat

[Bob McMahon via Iperf-users]

FYI, I've added a network power stat to iperf 2's TCP enhanced output.
It's mostly for convenience as there is no new information.  Network power
is defined as throughput / delay where the delay used is the sampled RTT
per that report interval.

Here's an example run:

[root@localhost iperf2-code]# src/iperf -c 192.168.1.1 -e -w 4m -t 60 -i 1

Client connecting to 192.168.1.1, TCP port 5001 with pid 12466
Write buffer size:  128 KByte
TCP window size: 7.63 MByte (WARNING: requested 3.81 MByte)

[  3] local 192.168.1.4 port 48054 connected with 192.168.1.1 port 5001
[ ID] IntervalTransferBandwidth   Write/Err  Rtry
 Cwnd/RTTNetPwr
[  3] 0.00-1.00 sec  64.0 MBytes   537 Mbits/sec  512/0  0
 5212K/16528 us  4060.31
[  3] 1.00-2.00 sec  64.8 MBytes   543 Mbits/sec  518/0  0
 5212K/15457 us  4392.53
[  3] 2.00-3.00 sec  57.2 MBytes   480 Mbits/sec  458/0  0
 5212K/15308 us  3921.54
[  3] 3.00-4.00 sec  57.2 MBytes   480 Mbits/sec  458/0  0
 5212K/31605 us  1899.41
[  3] 4.00-5.00 sec  59.6 MBytes   500 Mbits/sec  477/0  0
 5212K/23022 us  2715.72
[  3] 5.00-6.00 sec  59.9 MBytes   502 Mbits/sec  479/0  0
 5212K/29732 us  2111.65
^C[  3] 0.00-6.50 sec   394 MBytes   509 Mbits/sec  3154/0  0
 5212K/14198 us  4480.10

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3 query

[Bob McMahon via Iperf-users]

I cant' speak to iperf 3, but from an iperf 2 perspective this level of
"system testing" really isn't supported.  Tools from ixia
 would be my suggestion.

In general, it might be best to start with actionable effects, i.e what
changes a test will effect.  Then one can work backwards to the tooling.
For example, we mostly test WiFi drivers and can effect hw and sw in those
designs and implementations.  In that context, iperf works very well.  If
our company effected routers or load balancers, I don't think iperf is the
tool to use.

Bob

On Sun, Jul 29, 2018 at 11:40 PM, Mohanraj B  wrote:

> Hi,
>
> I have requirement for below use cases.
>
> Performance test with different types of traffic packets like video
> traffic, ICMP, HTTP, HTTPS, FTP, UDP,TCP.
> Different packets with different packet sizes like 64, 128, 256 … 9000
> (jumbo packets).
>
> I would like to know whether above use cases can be achieved using
> iperf3. If possible, please provide example configuration.
> So far I tested with TCP, UDP streams but quite not sure how to do
> other things with iperf3.
>
> iperf3 official page contain manual page for iperf3 with different
> client and server specific options. I would like to know what is the
> best mix of options(-b,-w,-t, etc) can be used in server/client
> command to measure accurate bandwidth of the network.
>
> Thanks and Regards,
> Mohan
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] Measure the amount of packets being processed by eth0 on Linux OS

[Bob McMahon via Iperf-users]

With iperf 2 you may be able to estimate this.  Use -b  to set the
network load  and -P to set the number of traffic threads.  The assumption
is one traffic thread per core.

Bob

On Wed, Jul 11, 2018 at 12:02 PM, Kaushal Shriyan 
wrote:

>
>
> On Thu, Jul 5, 2018 at 8:01 PM Kaushal Shriyan 
> wrote:
>
>>
>>
>> On Thu, Jul 5, 2018 at 7:18 PM Jeffrey Lane  wrote:
>>
>>> On Thu, Jul 5, 2018 at 5:07 AM, Sandro Bureca  wrote:
>>> > For linux the following command can be used:
>>> >
>>> > cat /sys/class/net/eth0/statistics/rx_packets
>>> > cat /sys/class/net/eth0/statistics/tx_packets
>>>
>>> Or you could just do this:
>>>
>>> watch -n1 netstat -ni
>>>
>>> Also, if you're looking to see what cores are being hammered during
>>> processing:
>>>
>>> cat /proc/interrupts and look for lines matching your device (if
>>> present):
>>>
>>>  139: 37  0  0  0  0
>>> 04605821  0  IR-PCI-MSI 1048576-edge  enp2s0
>>>  140:  0   2328  0  0   42268740
>>> 0  0  0  IR-PCI-MSI 1048577-edge  enp2s0-TxRx-0
>>>  141:  0  0243  0  0
>>> 0  01650980  IR-PCI-MSI 1048578-edge  enp2s0-tx-1
>>>  142:  0  0  08748551  0
>>> 0  0  0  IR-PCI-MSI 1048579-edge  enp2s0-tx-2
>>>  143:  0  0  0  0189
>>> 1341058  0  0  IR-PCI-MSI 1048580-edge
>>> enp2s0-tx-3
>>>
>>> That's for an 8 core Skylake CPU on my desktop.
>>>
>>> Something like this will let you see it in 1 second intervals to see
>>> which core is getting the interrupts during network stuff:
>>>
>>> watch -n1 "cat /proc/interrupts | grep enp2s0"
>>>
>>> YMMV and all that.
>>>
>>
>>
>> Thanks Jeff and Sandro Bureca for the reply.
>>
>> [ec2-user@ip-172-31-11-0 ~]$ cat /sys/class/net/eth0/
>> statistics/rx_packets
>> 1520936 -> Does it mean 1520936 packets? if it reports 1 does it mean 1
>> packet?
>> [ec2-user@ip-172-31-11-0 ~]$ cat /sys/class/net/eth0/
>> statistics/tx_packets
>> 1135781 -> Does it mean 1135781 packets?  if it reports 1 does it mean 1
>> packet?
>> [ec2-user@ip-172-31-11-0 ~]$
>>
>>
>> watch -n1 netstat -ni
>>
>> Every 1.0s: netstat -ni
>>
>>Thu Jul  5 14:26:03 2018
>>
>> Kernel Interface table
>> IfaceMTURX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR
>> Flg
>> eth0   9001  1520859  0  0 0   11356690   0 0 BMRU
>> lo 65536  2898393  0  0 0   28983930   0 0 LRU
>>
>> watch -n1 "cat /proc/interrupts | grep eth0"
>> Every 1.0s: cat /proc/interrupts | grep eth0
>>
>>   Thu Jul  5 14:25:29 2018
>>
>>  97:161  0  0  01885854  0
>>   0  0  xen-pirq-msi-x eth0-TxRx-0
>>  98:201  0  0  0  01613325
>>   0  0  xen-pirq-msi-x eth0-TxRx-1
>>  99: 54  0  0  0  0  0
>>   0  0  xen-pirq-msi-x eth0
>>
>> I look forward to hearing from you. How do i decide how many CPU cores i
>> need? Is there a thumb rule or any calculation to select AWS Instance for
>> example. Currently i have selected AWS t2.large instance type as per
>> https://aws.amazon.com/ec2/instance-types/ to set up Openswan IPsec VPN
>> tunnel without any basis. Correct me if i am wrong?
>>
>> I look forward to hearing from you
>>
>> Best Regards,
>>
>>
> Hi ,
>
> I will appreciate if someone can pitch in related to my earlier command
> output. Basically i am setting up AWS cloud instance viz how many CPU Cores
> to be selected to handle the network traffic. Is there a calculation to
> know how many cpu cores are needed for a specific network bandwidth?
>
> Best Regards,
>
> Kaushal
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iPerf's impact to network

[Bob McMahon via Iperf-users]

iperf generates traffic so it will use available bandwidth during the
duration of the test (set by -t) or use the amount specified by -b.

Bob

On Thu, Jun 21, 2018 at 12:15 PM, Peter Grafton  wrote:

> Hello,
> Can someone tell me what impact running iPerf on a live network will have
> to users at the time of the test? Can I run this as a quick 10-second test
> during production hours, or will it eat all available BW and needs to run
> off hours?
>
> Peter G
>
> --
> I
>  thought yesterday was the first day of the rest of my life but it turns
> out today is. - Steve Martin
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf for periodic udp traffic?

[Bob McMahon via Iperf-users]

I'm not sure what is meant by "synchronous instead of isochronous."

Bob

On Sat, May 26, 2018 at 12:25 AM, Ashish Kashinath <akash...@eng.ucsd.edu>
wrote:

> Thanks for this! Is there a way to generate synchronous udp traffic
> instead of it being isochronous?
>
> Regards,
>
> On Thu, May 24, 2018 at 8:08 PM, Bob McMahon <bob.mcma...@broadcom.com>
> wrote:
>
>> Not sure on iperf3.
>>
>> iperf 2.0.11 <https://sourceforge.net/projects/iperf2/?source=navbar>
>> supports isochronous traffic to better emulate things like video streams
>> and will burst packets.  It requires ./configure --enable-isochronous
>> before make.
>>
>> The client command line option is --isochronous=:,
>> and optionally --ipg  (defaults to 5 us)
>>
>> A way to send a burst every 1/60 seconds is something like
>> --isochronous=60:20m,0
>>
>> [root@localhost iperf2-code]# iperf -c 192.168.1.4 -u -i 1 -e
>> --isochronous=60:20m,0
>> 
>> Client connecting to 192.168.1.4, UDP port 5001 with pid 25669
>> UDP isochronous: 60 frames/sec mean=20.0 Mbit/s, variance=0.00 bit/s,
>> Period/IPG=16.67/0.005 ms
>> UDP buffer size:  208 KByte (default)
>> 
>> [  3] local 192.168.1.1 port 49458 connected with 192.168.1.4 port 5001
>> [ ID] Interval   Transfer Bandwidth  Write/Err  PPS
>> frames:tx/missed/slips
>> [  3] 0.00-1.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
>>  60/0/0
>> [  3] 1.00-2.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
>>  60/0/0
>> [  3] 2.00-3.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
>>  60/0/0
>> [  3] 3.00-4.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
>>  60/0/0
>> [  3] 4.00-5.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
>>  60/0/0
>> [  3] 5.00-6.00 sec  2.39 MBytes  20.0 Mbits/sec  1744/0 1744 pps
>>  60/0/0
>> [  3] 6.00-7.00 sec  2.42 MBytes  20.3 Mbits/sec  1763/0 1734 pps
>>  61/0/0
>> [  3] 7.00-8.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
>>  60/0/0
>> [  3] 8.00-9.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
>>  60/0/0
>> [  3] 0.00-10.02 sec  23.9 MBytes  20.0 Mbits/sec  17429/0 1740 pps
>> 600/0/0
>> [  3] Sent 17429 datagrams
>> [  3] Server Report:
>> [  3]  0.0-10.0 sec  23.9 MBytes  20.0 Mbits/sec  62.411 ms0/17429
>> (0%)
>>
>> Bob
>>
>> On Thu, May 24, 2018 at 3:02 PM, Ashish Kashinath <akash...@eng.ucsd.edu>
>> wrote:
>>
>>> Hi iperf-users. I am trying to use iperf to generate periodic stream of
>>> packets.
>>>
>>> Presently, I am using the command:
>>>
>>> iperf3 -c 192.168.1.60 -u -i 1 -b 750M -l 1K -t 600 to generate traffic
>>> of bandwidth 750Mb per second for 600 seconds.
>>>
>>> I am enabling UDP mode with a flag of -u and using a datagram size of
>>> 1KB using -l switch.
>>>
>>> Would this work in burst mode or would it generate a periodic stream of
>>> packets?
>>>
>>> --
>>> Regards,
>>> Ashish Kashinath
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iperf-users
>>>
>>>
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iPerf Window size

[Bob McMahon via Iperf-users]

Here is a good starting link:  https://fasterdata.es.net/host-tuning/linux/

Speaking for iperf2, the -w window size sets the socket buffer size.

There has been a lot of effort to reduce the windows per the buffer bloat
problem .

What exactly are you trying to influence with TCP by adjusting the window
sizes?

If you use iperf 2.0.11  with -e
and --vary-load you can get an idea how the congestion window and the RTT
are responding per the TCP offered load.

Bob



On Fri, May 25, 2018 at 1:39 PM, Kaliaperumal, Rajesh <
rajesh.kaliaperu...@arris.com> wrote:

> Hi all,
>
>   Can anyone explain or point me to some documentation that
> explains how iPerf3 and iPerf2 handles the window size parameter?
>
>
>
> I am trying to understand how to use this attribute for influencing the
> TCP performance.
>
>
>
> Thanks and regards,
>
> Rajesh K
>
>
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

[Iperf-users] iperf 2.0.11 released

[Bob McMahon via Iperf-users]

Hi All,

We've just released iperf 2.0.11 tested across all supported platforms.
 Here are the significant changes:

2.0.11 change set (as of May 24th, 2018)
o support for -b on server (read rate limiting)
o support for --isochronous traffic with optional frames per second, mean
and variance uses a log normal distribution (requires configure
w/-enable-isochronous and compile)
o support for --udp triggers (requires configure w/ --enable-udptriggers,
early code with very limited support)
o support for --udp-histogram with optional bin width and number of bins
(default is 1 millisecond bin width and 1000 bins)
o support for  frame (burst) latency histograms when --isochronous is set
o support for --tx-sync with -P for synchonrized writes.  Initial use is
for WiFi OFDMA latency testing.
o support for --incr-dstip with -P for simultaneous flows to multiple
destinations (use case is for OFDMA)
o support for --vary-load with optional weight, uses log normal
distribution (requires -b to set the mean)
o support for --l2checks to detect L2 length errors not detected by v4 or
v6 payload length errors (requires linux, berkeley packet filters BPFs and
AF_PACKET socket support)
o support for server joining mulitcast source specific multicast (S,G) and
(*,G) for both v4 and v6 on platforms that support it
o improved write counters (requires -e)
o accounting bug fix on client when write fails, this bug was introduced in
2.0.10
o slight restructure client/server traffic thread code for maintainability
o python: flow example script updates
o python: ssh node object using asyncio
o python: histograms in flows with plotting (assumed gnuplot available)
o python: hierarchical clustering of latency histograms (early code)
o man pages updates
o Note: latency histograms require client and server system clock
synchronization.   A GPS disciplined oscillator using Precision Time
Protocol works well for this.

A 2.0.11 zipped binary for windows will be uploaded soon.  (We're
investigating cross compiling using MXE http://mxe.cc/#introduction to
simplify the release process)

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf for periodic udp traffic?

[Bob McMahon via Iperf-users]

Not sure on iperf3.

iperf 2.0.11 
supports isochronous traffic to better emulate things like video streams
and will burst packets.  It requires ./configure --enable-isochronous
before make.

The client command line option is --isochronous=:,
and optionally --ipg  (defaults to 5 us)

A way to send a burst every 1/60 seconds is something like
--isochronous=60:20m,0

[root@localhost iperf2-code]# iperf -c 192.168.1.4 -u -i 1 -e
--isochronous=60:20m,0

Client connecting to 192.168.1.4, UDP port 5001 with pid 25669
UDP isochronous: 60 frames/sec mean=20.0 Mbit/s, variance=0.00 bit/s,
Period/IPG=16.67/0.005 ms
UDP buffer size:  208 KByte (default)

[  3] local 192.168.1.1 port 49458 connected with 192.168.1.4 port 5001
[ ID] Interval   Transfer Bandwidth  Write/Err  PPS
frames:tx/missed/slips
[  3] 0.00-1.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
 60/0/0
[  3] 1.00-2.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
 60/0/0
[  3] 2.00-3.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
 60/0/0
[  3] 3.00-4.00 sec  2.39 MBytes  20.0 Mbits/sec  1741/0 1741 pps
 60/0/0
[  3] 4.00-5.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
 60/0/0
[  3] 5.00-6.00 sec  2.39 MBytes  20.0 Mbits/sec  1744/0 1744 pps
 60/0/0
[  3] 6.00-7.00 sec  2.42 MBytes  20.3 Mbits/sec  1763/0 1734 pps
 61/0/0
[  3] 7.00-8.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
 60/0/0
[  3] 8.00-9.00 sec  2.38 MBytes  20.0 Mbits/sec  1740/0 1740 pps
 60/0/0
[  3] 0.00-10.02 sec  23.9 MBytes  20.0 Mbits/sec  17429/0 1740 pps
600/0/0
[  3] Sent 17429 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  23.9 MBytes  20.0 Mbits/sec  62.411 ms0/17429 (0%)

Bob

On Thu, May 24, 2018 at 3:02 PM, Ashish Kashinath 
wrote:

> Hi iperf-users. I am trying to use iperf to generate periodic stream of
> packets.
>
> Presently, I am using the command:
>
> iperf3 -c 192.168.1.60 -u -i 1 -b 750M -l 1K -t 600 to generate traffic of
> bandwidth 750Mb per second for 600 seconds.
>
> I am enabling UDP mode with a flag of -u and using a datagram size of 1KB
> using -l switch.
>
> Would this work in burst mode or would it generate a periodic stream of
> packets?
>
> --
> Regards,
> Ashish Kashinath
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf 3.1.3 TCP throughput issue

[Bob McMahon via Iperf-users]

The tcptrace tool may provide insights.  Also, if you
can test without -R then a run with iperf2
and -e could provide confirmation
of the expected throughputs and possibly some other information, e.g. the
RTT samples.  Also, with a 0.005 s sample interval one can get insights
into the TCP "ramp up."

Bob

On Sat, May 12, 2018 at 10:17 AM, Kaliaperumal, Rajesh <
rajesh.kaliaperu...@arris.com> wrote:

> Thanks Bruce. I had to do MSS mangling to avoid fragmentation of packets
> after ESP header addition.
>
> With single streams I get about 1/3rd of what I get using multiple streams
>
> Thanks and regards
> Rajesh
>
>
> > On May 12, 2018, at 2:34 AM, Bruce A. Mah  wrote:
> >
> > If memory serves me right, Kaliaperumal, Rajesh wrote:
> >> Hi Bruce,
> >>Single stream was pretty low and then I started trying multiple
> streams. I am expecting a throughput of the order of 70-100Mbps (my ISP DL
> being the limiting factor).
> >
> > Hmmm.  I don't have any good explanation off-hand.  The only two
> > thoughts I can think of right now are:  1) the IPsec tunnel and MSS
> > manipulation are unusual features of the path, and 2) that's a fairly
> > old version of iperf3.  I'm not sure if either of those are a factor,
> > just saying they stand out to me.
> >
> > Note that using multiple streams isn't necessarily going to scale the
> > throughput linearly.
> >
> > Bruce.
> >
> >> On 5/9/18, 4:02 PM, "Bruce A. Mah"  wrote:
> >>
> >>If memory serves me right, Kaliaperumal, Rajesh wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> Iperf version – iperf 3.1.3
> >>>
> >>>
> >>>
> >>> My set up:  iperf server (GCE) <=> Gateway VM (GCE) <=> IPsec server
> >>> (GCE) <=> WAN <=> Laptop with IPSec Client
> >>>
> >>>
> >>>
> >>> *My test:*
> >>>
> >>> Server – /iperf3 -s /
> >>>
> >>> Client – /iperf3 -c  -P 15 -R -w 768k/
> >>>
> >>> Due to IPsec header, my Gateway VM modifies the MSS size of the
> >>> SYN-SYN/ACK message so that the TCP segments are not fragmented after
> >>> IPSec ESP encryption.
> >>>
> >>>
> >>>
> >>> *My Observation:*
> >>>
> >>> When I perform a downlink test by using the “-R” option at the iperf
> >>> client side, my throughput has a lot of variation and quickly drops to
> 1
> >>> or 2 Mbps. In other words, the iPerf server reduces the rate at which
> it
> >>> pumps data. There are no packet drops on other VMs in my setup.
> >>>
> >>>
> >>>
> >>> I want to understand how iperf server determines the rate at which it
> >>> has to pump data?
> >>
> >>With those parameters (and thank you for providing that information),
> >>the server basically just sends data as fast as it can on the 15 TCP
> >>connections you specified by the -P parameter.  The speed at which it
> >>can send data is governed by the TCP congestion control and flow
> control
> >>algorithms.
> >>
> >>Of course those TCP connections will interact with each other, and
> any
> >>other network traffic along the path.  If the system isn't behaving
> in a
> >>way that makes sense to you, might I suggest trying your experiment
> with
> >>just a single TCP connection?  Also, what throughput were you
> expecting
> >>to get?
> >>
> >>Bruce.
> >>
> >>
> >>
> >>
> >
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3: abrupt interval issue

[Bob McMahon via Iperf-users]

Hi Nikita,

I don't know the iperf3 code.  We've been maintaining iperf2 mostly per
WiFi testing needs.  Bruce's original response suggested internal timers
not firing on time.

Bob

On Tue, May 8, 2018 at 12:26 AM, Nikita Gupta <nikitar...@gmail.com> wrote:

> Yes, iperf2 giving correct result. But can you explain why *iperf3* is
> not showing data of 1 Sec but of 1.24 sec?
>
> On Tue, 8 May 2018 at 10:37 AM, Bob McMahon <bob.mcma...@broadcom.com>
> wrote:
>
>> iperf2 seems to be indicating 83 socket writes per second with no write
>> errors.  The congestion window is 42K and the RTT is 3.5 milliseconds.
>> Nothing seems too unusual to me.
>>
>> Bob
>>
>> On Mon, May 7, 2018 at 8:05 PM, Nikita Gupta <nikitar...@gmail.com>
>> wrote:
>>
>>> Yeah Bob,
>>>
>>> Input command for iperf 2.0.10:
>>> iperf -c  -e -i 1 -t 10
>>> Output for iperf 2.0.10:
>>> [  3] 0.00-1.00 sec  10.4 MBytes  87.0 Mbits/sec  83/0  0
>>> 42K/3464 us
>>>
>>> input for iperf3:
>>> iperf3 -c  -i 1 -t 10
>>> Output for iperf3:
>>> [  5]   0.00-1.24   sec  5.60 MBytes  37.7 Mbits/sec0   38.2 KBytes
>>>
>>> I'm facing issue of time interval with iperf3.
>>>
>>> On Mon, May 7, 2018 at 9:10 PM, Bob McMahon <bob.mcma...@broadcom.com>
>>> wrote:
>>>
>>>> The client output for 2.0.10 with -e  and -i 1 could provide useful
>>>> information.
>>>>
>>>> Bob
>>>>
>>>> On Mon, May 7, 2018 at 1:32 AM, Nikita Gupta <nikitar...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bob,
>>>>>
>>>>> Working without issue: iperf-2.0.10
>>>>> Time interval issue: iperf-3.3, iperf-3.1, iperf-3.5, iperf-3.0
>>>>>
>>>>> Regards,
>>>>> Nikita
>>>>>
>>>>> On Sat, May 5, 2018 at 3:37 AM, Bob McMahon <bob.mcma...@broadcom.com>
>>>>> wrote:
>>>>>
>>>>>> what version of iperf did you use?  iperf -v should provide that.
>>>>>>
>>>>>> If it's a later version of iperf2 the output on the client of with
>>>>>> the -e option could be helpful.
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> On Thu, May 3, 2018 at 8:34 PM, Nikita Gupta <nikitar...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Bruce thanks for giving time on this issue.
>>>>>>>
>>>>>>> I am working on an embedded system with imx50.
>>>>>>> Server i'm using is RaspberryPi. Both the machines are connected on
>>>>>>> same network.
>>>>>>>
>>>>>>> Yes the system is a bit loaded. So this might be the reason.
>>>>>>> But if I reduce the window size then bandwidth also reduces and the
>>>>>>> time interval issue disappears.
>>>>>>>
>>>>>>> But with bandwidth of ~45M (which is the max it is showing) then it
>>>>>>> starts giving time interval issues.
>>>>>>>
>>>>>>> One more thing, I tried with iperf as well and its not giving any
>>>>>>> such issues on same machine with same server.
>>>>>>>
>>>>>>> On Thu, May 3, 2018 at 11:49 PM, Bruce A. Mah <b...@es.net> wrote:
>>>>>>>
>>>>>>>> If memory serves me right, Nikita Gupta wrote:
>>>>>>>> > Hi team,
>>>>>>>> >
>>>>>>>> > While checking network performance using iperf3, I'm facing
>>>>>>>> interval
>>>>>>>> > issue at client end. Below are the logs:
>>>>>>>> >
>>>>>>>> > [  5]   0.00-1.05   sec  11.2 MBytes  88.7 Mbits/sec0   42.4
>>>>>>>> > KBytes
>>>>>>>> > [  5]   1.05-2.01   sec  10.0 MBytes  88.2 Mbits/sec0   42.4
>>>>>>>> > KBytes
>>>>>>>> > [  5]   2.01-3.07   sec  11.2 MBytes  88.4 Mbits/sec0   42.4
>>>>>>>> > KBytes
>>>>>>>> > [  5]   3.07-4.05   sec  10.3 MBytes  88.5 Mbits/sec0   42.4
>>>>>>>> > KBytes
>>>>>>>> > [  5]   4.05-5.11   sec  11.2 MBytes  88.6 Mbits/sec

Re: [Iperf-users] iperf3: abrupt interval issue

[Bob McMahon via Iperf-users]

iperf2 seems to be indicating 83 socket writes per second with no write
errors.  The congestion window is 42K and the RTT is 3.5 milliseconds.
Nothing seems too unusual to me.

Bob

On Mon, May 7, 2018 at 8:05 PM, Nikita Gupta <nikitar...@gmail.com> wrote:

> Yeah Bob,
>
> Input command for iperf 2.0.10:
> iperf -c  -e -i 1 -t 10
> Output for iperf 2.0.10:
> [  3] 0.00-1.00 sec  10.4 MBytes  87.0 Mbits/sec  83/0  0
> 42K/3464 us
>
> input for iperf3:
> iperf3 -c  -i 1 -t 10
> Output for iperf3:
> [  5]   0.00-1.24   sec  5.60 MBytes  37.7 Mbits/sec0   38.2 KBytes
>
> I'm facing issue of time interval with iperf3.
>
> On Mon, May 7, 2018 at 9:10 PM, Bob McMahon <bob.mcma...@broadcom.com>
> wrote:
>
>> The client output for 2.0.10 with -e  and -i 1 could provide useful
>> information.
>>
>> Bob
>>
>> On Mon, May 7, 2018 at 1:32 AM, Nikita Gupta <nikitar...@gmail.com>
>> wrote:
>>
>>> Hi Bob,
>>>
>>> Working without issue: iperf-2.0.10
>>> Time interval issue: iperf-3.3, iperf-3.1, iperf-3.5, iperf-3.0
>>>
>>> Regards,
>>> Nikita
>>>
>>> On Sat, May 5, 2018 at 3:37 AM, Bob McMahon <bob.mcma...@broadcom.com>
>>> wrote:
>>>
>>>> what version of iperf did you use?  iperf -v should provide that.
>>>>
>>>> If it's a later version of iperf2 the output on the client of with the
>>>> -e option could be helpful.
>>>>
>>>> Bob
>>>>
>>>> On Thu, May 3, 2018 at 8:34 PM, Nikita Gupta <nikitar...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bruce thanks for giving time on this issue.
>>>>>
>>>>> I am working on an embedded system with imx50.
>>>>> Server i'm using is RaspberryPi. Both the machines are connected on
>>>>> same network.
>>>>>
>>>>> Yes the system is a bit loaded. So this might be the reason.
>>>>> But if I reduce the window size then bandwidth also reduces and the
>>>>> time interval issue disappears.
>>>>>
>>>>> But with bandwidth of ~45M (which is the max it is showing) then it
>>>>> starts giving time interval issues.
>>>>>
>>>>> One more thing, I tried with iperf as well and its not giving any such
>>>>> issues on same machine with same server.
>>>>>
>>>>> On Thu, May 3, 2018 at 11:49 PM, Bruce A. Mah <b...@es.net> wrote:
>>>>>
>>>>>> If memory serves me right, Nikita Gupta wrote:
>>>>>> > Hi team,
>>>>>> >
>>>>>> > While checking network performance using iperf3, I'm facing interval
>>>>>> > issue at client end. Below are the logs:
>>>>>> >
>>>>>> > [  5]   0.00-1.05   sec  11.2 MBytes  88.7 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   1.05-2.01   sec  10.0 MBytes  88.2 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   2.01-3.07   sec  11.2 MBytes  88.4 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   3.07-4.05   sec  10.3 MBytes  88.5 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   4.05-5.11   sec  11.2 MBytes  88.6 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   5.11-6.06   sec  10.0 MBytes  88.7 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   6.06-7.07   sec  10.7 MBytes  89.0 Mbits/sec0   42.4
>>>>>> > KBytes
>>>>>> > [  5]   7.07-8.02   sec  10.0 MBytes  88.6 Mbits/sec0   66.5
>>>>>> > KBytes
>>>>>> > [  5]   8.02-9.09   sec  11.1 MBytes  86.8 Mbits/sec0112
>>>>>> > KBytes
>>>>>> > [  5]   9.09-10.06  sec  10.0 MBytes  85.7 Mbits/sec0112
>>>>>> > KBytes
>>>>>> > - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>> > [ ID] Interval   Transfer Bitrate Retr
>>>>>> > [  5]   0.00-10.06  sec   106 MBytes  88.1 Mbits/sec
>>>>>> 0 sender
>>>>>> > [  5]   0.00-10.12  sec   106 MBytes  87.6
>>>>>> Mbits/sec
>>>>>> > receiver
>>>>>> >
>>>>>> > I checked github bug #125 which w

Re: [Iperf-users] iperf3: abrupt interval issue

[Bob McMahon via Iperf-users]

The client output for 2.0.10 with -e  and -i 1 could provide useful
information.

Bob

On Mon, May 7, 2018 at 1:32 AM, Nikita Gupta <nikitar...@gmail.com> wrote:

> Hi Bob,
>
> Working without issue: iperf-2.0.10
> Time interval issue: iperf-3.3, iperf-3.1, iperf-3.5, iperf-3.0
>
> Regards,
> Nikita
>
> On Sat, May 5, 2018 at 3:37 AM, Bob McMahon <bob.mcma...@broadcom.com>
> wrote:
>
>> what version of iperf did you use?  iperf -v should provide that.
>>
>> If it's a later version of iperf2 the output on the client of with the -e
>> option could be helpful.
>>
>> Bob
>>
>> On Thu, May 3, 2018 at 8:34 PM, Nikita Gupta <nikitar...@gmail.com>
>> wrote:
>>
>>> Hi Bruce thanks for giving time on this issue.
>>>
>>> I am working on an embedded system with imx50.
>>> Server i'm using is RaspberryPi. Both the machines are connected on same
>>> network.
>>>
>>> Yes the system is a bit loaded. So this might be the reason.
>>> But if I reduce the window size then bandwidth also reduces and the time
>>> interval issue disappears.
>>>
>>> But with bandwidth of ~45M (which is the max it is showing) then it
>>> starts giving time interval issues.
>>>
>>> One more thing, I tried with iperf as well and its not giving any such
>>> issues on same machine with same server.
>>>
>>> On Thu, May 3, 2018 at 11:49 PM, Bruce A. Mah <b...@es.net> wrote:
>>>
>>>> If memory serves me right, Nikita Gupta wrote:
>>>> > Hi team,
>>>> >
>>>> > While checking network performance using iperf3, I'm facing interval
>>>> > issue at client end. Below are the logs:
>>>> >
>>>> > [  5]   0.00-1.05   sec  11.2 MBytes  88.7 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   1.05-2.01   sec  10.0 MBytes  88.2 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   2.01-3.07   sec  11.2 MBytes  88.4 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   3.07-4.05   sec  10.3 MBytes  88.5 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   4.05-5.11   sec  11.2 MBytes  88.6 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   5.11-6.06   sec  10.0 MBytes  88.7 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   6.06-7.07   sec  10.7 MBytes  89.0 Mbits/sec0   42.4
>>>> > KBytes
>>>> > [  5]   7.07-8.02   sec  10.0 MBytes  88.6 Mbits/sec0   66.5
>>>> > KBytes
>>>> > [  5]   8.02-9.09   sec  11.1 MBytes  86.8 Mbits/sec0112
>>>> > KBytes
>>>> > [  5]   9.09-10.06  sec  10.0 MBytes  85.7 Mbits/sec0112
>>>> > KBytes
>>>> > - - - - - - - - - - - - - - - - - - - - - - - - -
>>>> > [ ID] Interval   Transfer Bitrate Retr
>>>> > [  5]   0.00-10.06  sec   106 MBytes  88.1 Mbits/sec0
>>>> sender
>>>> > [  5]   0.00-10.12  sec   106 MBytes  87.6 Mbits/sec
>>>> > receiver
>>>> >
>>>> > I checked github bug #125 which was addressing this specific issue.
>>>> But
>>>> > no help.
>>>> > I have tried iperf3.0.5, iperf3.1, iperf3.3, iperf3.5. In all
>>>> versions,
>>>> > I'm getting the same issue.
>>>> >
>>>> > P.S. Server(with same iperf3 version) provides result as expected
>>>> with 1
>>>> > sec time interval, but client provides data at different time
>>>> intervals
>>>> > in every iteration.
>>>> > Kindly look into the issue and do let me know if m missing something.
>>>>
>>>> What are the command line arguments you are using (both client and
>>>> server side, sanitize them as necessary0?  Also could you say something
>>>> about the environment you're running in?  In particular, what OS and
>>>> hardware on the client and server, and what kind of network path are you
>>>> going over?
>>>>
>>>> I rarely see issues like this (where the statistics printing intervals
>>>> are not aligned to whole second boundaries) in the middle of a test,
>>>> although it's been known to happen at the end of a test, for conditions
>>>> that only happen at the end of a test.
>>>>
>>>> It seems like the timers within iperf3 that control when statistics and

Re: [Iperf-users] Multiple tests on the same port

[Bob McMahon via Iperf-users]

2.0.5 is old and has multiple bugs so I wouldn't use it.  Get a later
version of that or try iperf 3

https://sourceforge.net/projects/iperf2/
http://software.es.net/iperf/obtaining.html

2.0 does support multiple clients.  There is no fixed limit to the number
of clients rather it will be limited by the compute resources, e.g. memory,
number CPUs, etc.

Also, with 2.0.11a and testing with TCP and want to limit the bandwidth per
client use the -b option on the server, e.g. iperf -s -b 10M will limit the
server read rate to 10 Mbs which will in turn flow control the clients to
that rate.

Bob

On Sun, Apr 22, 2018 at 2:50 AM, Ayrton Senna 
wrote:

> Hello,
>
> I am new to performance testing, and I would like confirm if iperf2 can be
> used in the use case I will describe here, which is required by my employer.
>
>
> I am using iperf 2.0.5 on a single server (Ubuntu 16.04.2) and on multiple
> clients (Debian 8) to test download and upload bandwidth towards this
> server using  the "-d" option. .
>
> My question is this: Can the server successfully accept and complete
> simultaneous tests from different client on the same interface, IP address,
> and port?
>
> The number of client is currently around 250 (expected to grow to around
> 950.)
>
> Server command: iperf -s -p 5002 -f m
> All clients using the command: iperf -c serverIP -d -p 5002 -f m
>
> If the answer is Yes, what are the limitations to this use case? (ex. up
> to how many client can be used.)
>
>
> Regards,
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: [Iperf-users] iperf3 and 100Gb

[Bob McMahon via Iperf-users]

Seems reasonable to me though I'm not an iperf3 expert.

Bob

PS.  As a side note, with iperf2
 which
does support multiple traffic threads, you can get 4 threads using -P 4.

On Tue, Apr 17, 2018 at 6:19 AM, Jeffrey Lane  wrote:

> Hi all,
>
> I have what is kind of a silly question, but who has some experience
> testing 100Gb with iperf3?
>
> I  just wanted to validate something with iperf3 to see if it is
> reasonable.
>
> With a single process running, the most I've been able to get out of a
> 100Gb network port is a burst of about 65Gb/s with sustained averages
> of around 50-55Gb/s.
>
> This is after a LOT of kernel tweaks, PCIe tweaks, and network config
> tweaks.
>
> So at this point, I'm thinking that what I'm seeing is a hardware
> bottleneck, since iperf3 isn't multi-threaded.
>
> What I wanted to validate, to get around that is this:
>
> On the target side, I've kicked off four iperf3 processes all bound to
> the same IP but listening on a different port.  Now, on the client
> side, I kick off four iperf3 instances, one per remote port.  After 30
> minutes of testing, each instance returns an average throughput of
> about 23Gb/s.
>
> So in that scenario is it reasonable that 4 parallel threads reporting
> 23Gb/s can be aggregated to assume we're actually seeing throughput of
> 92Gb/s on the 100Gb port (thus nearly saturated)?
>
> Thanks,
>
> Jeff
>
> --
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Iperf-users mailing list
> Iperf-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iperf-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users