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

[rjmcmahon <rjmcmahon@rjmcmahon.com>]

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.