[LibreQoS] [Make-wifi-fast] [Rpm] make-wifi-fast 2016 & crusader

rjmcmahon rjmcmahon at rjmcmahon.com
Wed Dec 7 14:28:43 EST 2022

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:


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 

Note: Some GPS atomic clock options for RPi:

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 

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. 

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


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

> 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 at 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 at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm
>> -------------------------
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the LibreQoS mailing list