Bob, I appreciate you giving it some consideration.
On Tue, Dec 1, 2020, 5:52 PM Bob McMahon <bob.mcma...@broadcom.com> 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 <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 >>>>>>>>>>>>> >>>>>>>>>>>>
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
