[Rpm] make-wifi-fast 2016 & crusader

[Rpm] make-wifi-fast 2016 & crusader

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

This is where things stood on the wifi front, back in 2016. Nobody
understood us...

https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#

So I sort of enjoyed re-reading that this morning, and all the
enthusiastic commentary we'd had on it. Perhaps we can reshape it and
find ways to move forward today?

I am happy to have seen so many products hitting the market 5+ years
later that leverage this work, many openwrt derived, like evenroute,
quantum, and openwifi, others from pure linux, like eero and google
fiber, and so far as I can tell, in many a chromebook, and of course
ios and osx.

Still, there was so much work left to be done, and the work applied to
all forms of wireless technology, be it 6 or 12ghz, or 60ghz, or
starlink. Just the other day I was watching a 5G engineer that was
struggling to get decent simultaneous throughput up and down, the test
tool showing that, but not the 25 seconds of buffering built into the
rmnet driver in poor conditions, and "only" 150ms perfect ones. This
test tool shows "perfect" throughput for this device:

https://www.spinics.net/lists/netdev/msg865852.html
(anyone know which tool it was? see image here:
https://drive.google.com/file/d/1gSbozrtd9h0X63i6vdkNpN68d-9sg8f9/view
)

vs the actual, underlying, unusable 25 seconds!!! - result - if only
that test tool attempted to start up even one more flow partially
through the test, perhaps we'd be getting somewhere. An increasingly
favorite test of mine is the staggered start "squarewave" tests in the
flent suite. For those that haven't tried it, crusader is the first
tool I've seen that not only has a staggered start latency under load
test, but as its written in rust, runs on every OS in the planet. Give
it a shot?

https://github.com/Zoxc/crusader/releases/tag/v0.0.9-testing

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: rrul_-_bad_tx_aggr.png --]
[-- Type: image/png, Size: 232329 bytes --]

Re: [Rpm] make-wifi-fast 2016 & crusader

[rjmcmahon]

Nice write up and work over the years.

On tooling:

iperf 2 supports full duplex, multiple parallel streams, tx start times, 
bounceback, isochronous, etc. Man page is here

https://iperf2.sourceforge.io/iperf-manpage.html

The flows code in the flows directory

https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/

is written in python 3 and leverages asyncio.

https://docs.python.org/3/library/asyncio.html

This is all released as open source.

Bob
> This is where things stood on the wifi front, back in 2016. Nobody
> understood us...
> 
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
> 
> So I sort of enjoyed re-reading that this morning, and all the
> enthusiastic commentary we'd had on it. Perhaps we can reshape it and
> find ways to move forward today?
> 
> I am happy to have seen so many products hitting the market 5+ years
> later that leverage this work, many openwrt derived, like evenroute,
> quantum, and openwifi, others from pure linux, like eero and google
> fiber, and so far as I can tell, in many a chromebook, and of course
> ios and osx.
> 
> Still, there was so much work left to be done, and the work applied to
> all forms of wireless technology, be it 6 or 12ghz, or 60ghz, or
> starlink. Just the other day I was watching a 5G engineer that was
> struggling to get decent simultaneous throughput up and down, the test
> tool showing that, but not the 25 seconds of buffering built into the
> rmnet driver in poor conditions, and "only" 150ms perfect ones. This
> test tool shows "perfect" throughput for this device:
> 
> https://www.spinics.net/lists/netdev/msg865852.html
> (anyone know which tool it was? see image here:
> https://drive.google.com/file/d/1gSbozrtd9h0X63i6vdkNpN68d-9sg8f9/view
> )
> 
> vs the actual, underlying, unusable 25 seconds!!! - result - if only
> that test tool attempted to start up even one more flow partially
> through the test, perhaps we'd be getting somewhere. An increasingly
> favorite test of mine is the staggered start "squarewave" tests in the
> flent suite. For those that haven't tried it, crusader is the first
> tool I've seen that not only has a staggered start latency under load
> test, but as its written in rust, runs on every OS in the planet. Give
> it a shot?
> 
> https://github.com/Zoxc/crusader/releases/tag/v0.0.9-testing
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

Re: [Rpm] [Make-wifi-fast] make-wifi-fast 2016 & crusader

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]

Hi Bob,

What simple end users would need is (semi-)public iperf2 servers accessible over the internet to be comparably easy to use as iperf3....

Regards
        Sebastian

On 6 December 2022 18:46:18 CET, rjmcmahon via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
>Nice write up and work over the years.
>
>On tooling:
>
>iperf 2 supports full duplex, multiple parallel streams, tx start times, bounceback, isochronous, etc. Man page is here
>
>https://iperf2.sourceforge.io/iperf-manpage.html
>
>The flows code in the flows directory
>
>https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/
>
>is written in python 3 and leverages asyncio.
>
>https://docs.python.org/3/library/asyncio.html
>
>This is all released as open source.
>
>Bob
>> This is where things stood on the wifi front, back in 2016. Nobody
>> understood us...
>> 
>> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
>> 
>> So I sort of enjoyed re-reading that this morning, and all the
>> enthusiastic commentary we'd had on it. Perhaps we can reshape it and
>> find ways to move forward today?
>> 
>> I am happy to have seen so many products hitting the market 5+ years
>> later that leverage this work, many openwrt derived, like evenroute,
>> quantum, and openwifi, others from pure linux, like eero and google
>> fiber, and so far as I can tell, in many a chromebook, and of course
>> ios and osx.
>> 
>> Still, there was so much work left to be done, and the work applied to
>> all forms of wireless technology, be it 6 or 12ghz, or 60ghz, or
>> starlink. Just the other day I was watching a 5G engineer that was
>> struggling to get decent simultaneous throughput up and down, the test
>> tool showing that, but not the 25 seconds of buffering built into the
>> rmnet driver in poor conditions, and "only" 150ms perfect ones. This
>> test tool shows "perfect" throughput for this device:
>> 
>> https://www.spinics.net/lists/netdev/msg865852.html
>> (anyone know which tool it was? see image here:
>> https://drive.google.com/file/d/1gSbozrtd9h0X63i6vdkNpN68d-9sg8f9/view
>> )
>> 
>> vs the actual, underlying, unusable 25 seconds!!! - result - if only
>> that test tool attempted to start up even one more flow partially
>> through the test, perhaps we'd be getting somewhere. An increasingly
>> favorite test of mine is the staggered start "squarewave" tests in the
>> flent suite. For those that haven't tried it, crusader is the first
>> tool I've seen that not only has a staggered start latency under load
>> test, but as its written in rust, runs on every OS in the planet. Give
>> it a shot?
>> 
>> https://github.com/Zoxc/crusader/releases/tag/v0.0.9-testing
>> 
>> _______________________________________________
>> Rpm mailing list
>> Rpm@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/rpm
>_______________________________________________
>Make-wifi-fast mailing list
>Make-wifi-fast@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/make-wifi-fast
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4139 bytes --]

Re: [Rpm] [Make-wifi-fast] make-wifi-fast 2016 & crusader

[rjmcmahon]

Hi Sebastian,

Per Aristotle: "That which is common to the greatest number gets the 
least amount of care. Men pay most attention to what is their own: they 
care less for what is common."

I think a challenge for many of us providing open source tooling is the 
lack of resource support to supply goods for all. Both the iperf 2 and 
iperf 3 teams are under-resourced so we try not to duplicate each other 
too much except for where that duplication adds value (e.g. having two 
independently written socket measurement tools.) The iperf 3 team has 
provided public servers, I think at their costs.

I've been holding off on iperf 2 public servers until I found an 
additional value add and a way to pay for them. Much of the iperf 2 work 
has been around one way delay (OWD) or latency. Doing this well requires 
GPS clock sync on both the data center servers and the end host devices. 
I checked into this a few years ago and found that this level of clock 
sync wasn't available via rented servers (e.g. linode or Hurricane 
Electric) so I put on hold any further investigation of public servers 
for iperf 2 as being redundant with iperf 3. Those that need true e2e 
latency (vs RTTs) have to build their own so-to-speak.

I know of two nonprofit measurement labs being mlabs and ripe (there may 
be more) that could take an interest but neither has:

https://www.ripe.net/
https://www.measurementlab.net/

There could be a market opportunity for somebody to build a measurement 
system in the cloud that supported any generic sensors and could signal 
anomalies. Then one could connect iperf 2 public servers to that as an 
offering.

Note: Some GPS atomic clock options for RPi:
https://store.uputronics.com/index.php?route=product/product&product_id=81
https://store.timebeat.app/products/gnss-raspberry-pi-cm4-module?variant=41934772764843

Also needed is the latest iperf 2 on an openwrt router. Better may be to 
have that router also run ptp4l or equivalent and behave as a PTP 
grandmaster.

Unfortunately, my day job requires me to focus on "shareholder 
interests" and, in that context, it's very difficult to provide public 
goods that are nonrivalrous and nonexcludable. 
https://tinyurl.com/mr63p52k

Finally, we all have to deal with "why we sleep" in order to be most 
productive (despite what Mr. Musk thinks.)

https://en.wikipedia.org/wiki/Why_We_Sleep

and there are only so many "awake hours" for us "non-exceptional" 
engineers ;-) (A joke, everybody has value by my book.)

Thanks,
Bob
> Hi Bob,
> 
> What simple end users would need is (semi-)public iperf2 servers
> accessible over the internet to be comparably easy to use as
> iperf3....
> 
> Regards
>         Sebastian
> 
> On 6 December 2022 18:46:18 CET, rjmcmahon via Make-wifi-fast
> <make-wifi-fast@lists.bufferbloat.net> wrote:
> 
>> Nice write up and work over the years.
>> 
>> On tooling:
>> 
>> iperf 2 supports full duplex, multiple parallel streams, tx start
>> times, bounceback, isochronous, etc. Man page is here
>> 
>> https://iperf2.sourceforge.io/iperf-manpage.html
>> 
>> The flows code in the flows directory
>> 
>> https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/
>> 
>> is written in python 3 and leverages asyncio.
>> 
>> https://docs.python.org/3/library/asyncio.html
>> 
>> This is all released as open source.
>> 
>> Bob
>>> This is where things stood on the wifi front, back in 2016. Nobody
>>> understood us...
>>> 
>>> 
>> 
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit#
>>> 
>>> So I sort of enjoyed re-reading that this morning, and all the
>>> enthusiastic commentary we'd had on it. Perhaps we can reshape it
>>> and
>>> find ways to move forward today?
>>> 
>>> I am happy to have seen so many products hitting the market 5+
>>> years
>>> later that leverage this work, many openwrt derived, like
>>> evenroute,
>>> quantum, and openwifi, others from pure linux, like eero and
>>> google
>>> fiber, and so far as I can tell, in many a chromebook, and of
>>> course
>>> ios and osx.
>>> 
>>> Still, there was so much work left to be done, and the work
>>> applied to
>>> all forms of wireless technology, be it 6 or 12ghz, or 60ghz, or
>>> starlink. Just the other day I was watching a 5G engineer that was
>>> struggling to get decent simultaneous throughput up and down, the
>>> test
>>> tool showing that, but not the 25 seconds of buffering built into
>>> the
>>> rmnet driver in poor conditions, and "only" 150ms perfect ones.
>>> This
>>> test tool shows "perfect" throughput for this device:
>>> 
>>> https://www.spinics.net/lists/netdev/msg865852.html
>>> (anyone know which tool it was? see image here:
>>> 
>> 
> https://drive.google.com/file/d/1gSbozrtd9h0X63i6vdkNpN68d-9sg8f9/view
>>> )
>>> 
>>> vs the actual, underlying, unusable 25 seconds!!! - result - if
>>> only
>>> that test tool attempted to start up even one more flow partially
>>> through the test, perhaps we'd be getting somewhere. An
>>> increasingly
>>> favorite test of mine is the staggered start "squarewave" tests in
>>> the
>>> flent suite. For those that haven't tried it, crusader is the
>>> first
>>> tool I've seen that not only has a staggered start latency under
>>> load
>>> test, but as its written in rust, runs on every OS in the planet.
>>> Give
>>> it a shot?
>>> 
>>> https://github.com/Zoxc/crusader/releases/tag/v0.0.9-testing
>>> -------------------------
>>> Rpm mailing list
>>> Rpm@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm
>> 
>> -------------------------
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> 
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.