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
