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

[Bob McMahon via Iperf-users]

Go here

https://sourceforge.net/projects/iperf/lists/iperf-users/unsubscribe

Bob

On Fri, Dec 4, 2020 at 2:24 AM shaukath ali via Iperf-users <
iperf-users@lists.sourceforge.net> wrote:

> Hi Mates, How to unsubscribe from this alias. Regds, Shaukath.
>
> From: Bob McMahon 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 really helps with iperf
> 2.0.14 latency features (see the client side --trip-times option.
> <https://iperf2.sourceforge.io/iperf-manpage.html=UHZTOVUzAnJSdlVgV3dTMFM4>)
>
>
> We've also found that, while RTT is of interest to network stack
> engineers, it's the end/end delay that impacts user experience.  That's why
> we've added write-start to read-finished latencies supporting both
> parametric and non-parametric distributions (i.e. mean/min/max/stdev and
> histograms.). Similar for video frame latencies, first packet of frame
> start to final packet of frame read.
>
> It seems good for tooling to include direct latency measurements as
> standard practice. Ping is a suboptimal technique for multiple reasons
> though it doesn't require clock sync.
>
> Bob
>
> On Thu, Dec 3, 2020 at 4:00 AM Tim Chown  wrote:
>
>> 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 McMahon via Iperf-users <
>> iperf-users@lists.sourceforge.net> 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 
>> 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.)  The iperf hosts don't need to run python just ssh pipes and have
>> a local iperf binary.
>> >
>> > Async or event based 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 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 
>> 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 Communicatio

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

[shaukath ali via Iperf-users]

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 - Throughput ramp up

Sorry for being off topic but curious about perfSonars ability to sync the 
clocks to the GPS atomic clocks. We found this really helps with iperf 2.0.14 
latency features (see the client side --trip-times option.)  

Weve also found that, while RTT is of interest to network stack engineers, 
its the end/end delay that impacts user experience.  Thats why 
weve added write-start to read-finished latencies supporting both 
parametric and non-parametric distributions (i.e. mean/min/max/stdev and 
histograms.). Similar for video frame latencies, first packet of frame start to 
final packet of frame read.
It seems good for tooling to include direct latency measurements as standard 
practice. Ping is a suboptimal technique for multiple reasons though it 
doesnt require clock sync.

Bob
On Thu, Dec 3, 2020 at 4:00 AM Tim Chown tim.ch...@jisc.ac.uk wrote:
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 McMahon via Iperf-users 
iperf-users@lists.sourceforge.net wrote:

 

 Ok, after some further discussions weve 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 dont 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 dont require 
source and sink knowledge, e.g. a video stream is defined by the source not the 
receiver, so thats 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.  Ive 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 pythons 
asyncio.)  The iperf hosts dont need to run python just ssh pipes and have 
a local iperf binary. 

 

 Async or event based programming is a bit more challenging than procedural 
based so keep that in mind.  Simple traffic is easy as its just 
installations of flows then flow commence and flow cease 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 thats 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. 
Well 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 doesnt 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

 

 Id suggest writing a python script using pyflows if you need the full 
duplex case to be synchronized

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

[Tim Chown via Iperf-users]

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 McMahon via Iperf-users 
>  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  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.)  
> The iperf hosts don't need to run python just ssh pipes and have a local 
> iperf binary. 
> 
> Async or event based 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 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  
> 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  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  --full-duplex -u --sweep-range=1m,10m,1m 
> --sweep-step 10 -i 1 -l 200 -S 0xc0
>   • iperf -c  --reverse -u --sweep-range=1m,10m,1m 
> --sweep-step 10 -i 1 -l 200 -S 0xc0
>   • iperf -c  --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
> 
> I'd suggest writing a python script using pyflows 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  
> 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 

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

[Bob McMahon via Iperf-users]

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 
wrote:

> Bob,
>
> I appreciate you giving it some consideration.
>
> On Tue, Dec 1, 2020, 5:52 PM Bob McMahon  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 
>> 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 .)  The iperf
>>> hosts don't need to run python just ssh pipes and have a local iperf
>>> binary.
>>>
>>> Async or event based 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
>>>  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 
>>> 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 
 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  --full-duplex -u
>--sweep-range=1m,10m,1m --sweep-step 10 -i 1 -l 200 -S 0xc0
>- iperf -c  --reverse -u --sweep-range=1m,10m,1m
>--sweep-step 10 -i 1 -l 200 -S 0xc0
>- iperf -c  --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 
>
> I'd suggest writing a python script using pyflows
>  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 

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

[Bob McMahon via Iperf-users]

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  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 .)  The iperf
> hosts don't need to run python just ssh pipes and have a local iperf
> binary.
>
> Async or event based 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
>  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 
> 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 
>> 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  --full-duplex -u --sweep-range=1m,10m,1m
>>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>>- iperf -c  --reverse -u --sweep-range=1m,10m,1m
>>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>>- iperf -c  --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 
>>>
>>> I'd suggest writing a python script using pyflows
>>>  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 
>>> 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 

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

[Bob McMahon via Iperf-users]

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
.)  The iperf hosts don't
need to run python just ssh pipes and have a local iperf binary.

Async or event based 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
 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 
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 
> 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  --full-duplex -u --sweep-range=1m,10m,1m
>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>- iperf -c  --reverse -u --sweep-range=1m,10m,1m
>>--sweep-step 10 -i 1 -l 200 -S 0xc0
>>- iperf -c  --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 
>>
>> I'd suggest writing a python script using pyflows
>>  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 
>> 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 

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

[Bob McMahon via Iperf-users]

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 --sweep-range=1m,10m,1m
   --sweep-step 10 -i 1 -l 200 -S 0xc0
   - iperf -c  --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 

I'd suggest writing a python script using pyflows
 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 
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 
> 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 
>> 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 
>>> 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 
 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 
> 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?
>>

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

[Craig Reeves]

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

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

[Bob McMahon via Iperf-users]

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

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

[Bob McMahon via Iperf-users]

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

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

[Craig Reeves]

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

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

[Bob McMahon via Iperf-users]

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

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

[Craig Reeves]

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

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

[Craig Reeves]

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

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

[Bob McMahon via Iperf-users]

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

[Iperf-users] Feature - Throughput ramp up

[Craig Reeves]

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