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 <bob.mcma...@broadcom.com> 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 <craigree...@ambit-llc.com> > 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 <bob.mcma...@broadcom.com> >> 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 <customer host> --full-duplex -u --sweep-range=1m,10m,1m >>> --sweep-step 10 -i 1 -l 200 -S 0xc0 >>> - iperf -c <customer host> --reverse -u --sweep-range=1m,10m,1m >>> --sweep-step 10 -i 1 -l 200 -S 0xc0 >>> - iperf -c <customer host> --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 <craigree...@ambit-llc.com> >>> 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 <bob.mcma...@broadcom.com> >>>> 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 < >>>>> craigree...@ambit-llc.com> 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 <bob.mcma...@broadcom.com> >>>>>> 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 < >>>>>>> craigree...@ambit-llc.com> 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 < >>>>>>>> bob.mcma...@broadcom.com> 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 < >>>>>>>>> craigree...@ambit-llc.com> 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 < >>>>>>>>>> bob.mcma...@broadcom.com> 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
