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