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

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

[Sebastian Moeller]

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@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@rjmcmahon.com>
> Cc: rjmcmahon via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net>, Dave Täht <dave.taht@gmail.com>, Rpm <rpm@lists.bufferbloat.net>, libreqos <libreqos@lists.bufferbloat.net>, Dave Taht via Starlink <starlink@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
> 
> Hi Bob,
> 
> thanks for the detailed response.
> 
> 
>> On Dec 7, 2022, at 20:28, rjmcmahon <rjmcmahon@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

Re: [LibreQoS] [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@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@rjmcmahon.com>
>> Cc: rjmcmahon via Make-wifi-fast 
>> <make-wifi-fast@lists.bufferbloat.net>, Dave Täht 
>> <dave.taht@gmail.com>, Rpm <rpm@lists.bufferbloat.net>, libreqos 
>> <libreqos@lists.bufferbloat.net>, Dave Taht via Starlink 
>> <starlink@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
>> 
>> Hi Bob,
>> 
>> thanks for the detailed response.
>> 
>> 
>>> On Dec 7, 2022, at 20:28, rjmcmahon <rjmcmahon@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm