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

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