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

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 real

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

Hi Mates, How to unsubscribe from this alias. Regds, Shaukath. From: Bob McMahon via Iperf-users iperf-users@lists.sourceforge.net Sent: Thu, 03 Dec 2020 23:05:27 To: Tim Chown tim.ch...@jisc.ac.uk Cc: iPerf User Group iperf-users@lists.sourceforge.net Subject: Re: [Iperf-users] Feature

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

[Iperf-users] Feature - Throughput ramp up

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