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 <craigree...@ambit-llc.com> wrote: > 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
