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

[rjmcmahon]

Thanks for the well-written response Sebastian. I need to think more 
about the load vs no load OWD differentials and maybe offer that as an 
integrated test. Thanks for bringing it up (again.) I do think a 
low-duty cycle bounceback test to the AP could be interesting too.

I don't know of any projects working on iperf 2 & containers but it has 
been suggested as useful.

Bob

> Mail mail provider unhelpfully labelled my post as SPAM, and
> apparently all receivers rejected to receive my "SPAM"
> Hence I try forwarding a slightly edited version of my response below,
> hoping not to trigger GMX's SPAM detection again.
> 
> 
>> Begin forwarded message:
>> 
>> From: Sebastian Moeller <moeller0 at gmx.de>
>> Subject: Re: [Make-wifi-fast] [Rpm] make-wifi-fast 2016 & crusader
>> Date: December 8, 2022 at 11:15:12 GMT+1
>> To: rjmcmahon <rjmcmahon at rjmcmahon.com>
>> Cc: rjmcmahon via Make-wifi-fast 
>> <make-wifi-fast at lists.bufferbloat.net>, Dave Täht 
>> <dave.taht at gmail.com>, Rpm <rpm at lists.bufferbloat.net>, libreqos 
>> <libreqos at lists.bufferbloat.net>, Dave Taht via Starlink 
>> <starlink at lists.bufferbloat.net>, bloat <bloat at lists.bufferbloat.net>
>> 
>> Hi Bob,
>> 
>> thanks for the detailed response.
>> 
>> 
>>> On Dec 7, 2022, at 20:28, rjmcmahon <rjmcmahon at rjmcmahon.com> wrote:
>>> 
>>> 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.
>> 
>> 	[SM] I should probably clarify my position, I was not trying to argue 
>> that you (or your employer) should operate public iperf2 servers, but 
>> that the availability of such servers probably is what made iperf3 the 
>> most popular of the iperf2/iperf3/netperf triple. I did not realize 
>> that the iperf3 team operates some of the public servers, as I have 
>> already seen ISPs (see e.g. hxxps://speedtest.wtnet.de) that offer 
>> iperf3 as mean for their existing users to run speedtest via iperf3. 
>> So my argument should gone more along the lines of, "to make iperf2 as 
>> popular as it deserves to be some publicity and available servers will 
>> help a lot". And actually having servers operated by other parties 
>> than the toll maker is an added "vote of confidence".
>> 
>> 
>>> I've been holding off on iperf 2 public servers until I found an 
>>> additional value add and a way to pay for them.
>> 
>> 	[SM] Understood, and I formulated inartfully, implying you should 
>> host iperf2 servers; that was not my intent.
>> 
>>> 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.
>> 
>> 	[SM] Yepp, except for congestion detection all that is really 
>> required is sufficiently stable clocks, as the delay differences 
>> between idle and loaded tests are quite informative and offering OWDs 
>> allows to pinpoint the direction of congestion.
>> 
>>> I know of two nonprofit measurement labs being mlabs and ripe (there 
>>> may be more) that could take an interest but neither has:
>>> 
>>> hxxps://www.ripe.net/
>>> hxxps://www.measurementlab.net/
>> 
>> 	[SM] I think ripe especially their ATLAS network is somewhat 
>> "sensitive" about throughput tests, as quite some nodes likely are 
>> operated by enthusiasts in their leaf networks that are not well 
>> suited as generic speedtest servers... (however that would allow great 
>> studies of achievable throughput comparing different ASs).
>> 
>>> 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:
>>> hxxps://store.uputronics.com/index.php?route=product/product&product_id=81
>>> hxxps://store.timebeat.app/products/gnss-raspberry-pi-cm4-module?variant=41934772764843
>> 
>> 	[SM] I followed your lead several moths ago, and have an 
>> GPS-disciplined NTP server in my homenetwork already, so I am prepared 
>> for true OWD measurements ;)
>> 
>> 
>>> Also needed is the latest iperf 2 on an openwrt router.
>> 
>> 	[SM] That will work well for the low throughput test, but I often see 
>> that routers that are fully capable of routing X Mbps get into issues 
>> when trying to source and/or sink the same X Mbps, so it becomes 
>> essential to monitor router "load" while running tests (something that 
>> is also still on the TODO list for cake-autorate, we should throttle 
>> our shapers if the traffic load exceeds a router's capability to 
>> schedule CPU slots timely to the shaper qdiscs).
>> 
>>> Better may be to have that router also run ptp4l or equivalent and 
>>> behave as a PTP grandmaster.
>> 
>> 	[SM] In OpenWrt it is simple to enable an NTP server would it not be 
>> enough to feed that server via PTP? Otherwise the router would need to 
>> include the high precision clock. And as much as I love my GPS 
>> disciplined NTP server, I have reservations whether I think it a great 
>> idea to make GPS receivers a default router feature (I think this will 
>> play into the hand of location restricted internet access/offering 
>> which could easily be abused* and unlike geoIP it might be tempting to 
>> use that information at court as well).
>> 
>>> 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. 
>>> hxxps://tinyurl.com/mr63p52k
>>> 
>>> Finally, we all have to deal with "why we sleep" in order to be most 
>>> productive (despite what Mr. Musk thinks.)
>>> 
>>> hxxps://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.)
>> 
>> 	[SM] ;) the time-limit also applies for non-engineers as well 
>> (independent of exceptions). Fun fact, for most measures most of us 
>> fall into the non-exceptional category anyway.
>> 
>> Regards
>> 	Sebastian
>> 
>> P.S.: Getting iperf2 into OpenWrt and offering a howto how to make 
>> that available to the outside would be great (as would easy recipes 
>> how to install iperf2 on containers or VPS). I admit however that I 
>> did not do my research here and both howto and recipes might already 
>> exist. And again this is not intended as something for your 
>> "plate"/TODO list just as relative simple/low cost/low effort ways to 
>> make iperf2 more salient generally.
>> 
>> 
>>> 
>>> Thanks,
>>> Bob
> 
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm