From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 657953B29D; Thu, 8 Dec 2022 14:04:14 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 8EBF01B280; Thu, 8 Dec 2022 11:04:13 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 8EBF01B280 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1670526253; bh=tTl4FfEFXtONHNrwQyB9HFpk/dohJK87/Wv0QxRDKrY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V8xkb7Om4pfP64bevF35jEA9uMLwuqSgaotgXBZznN/iyQ17R0TNtAfm+ycNsp4St niXssCgbJzovC9hs1Rhwl5HhB1rE6NsyM3Sfx8N13jfruCRsldkX7fgsxQQlzvTYs+ PVrwnFMrCjpLhceQnygZ0czK635/fwSFviwGDtE4= MIME-Version: 1.0 Date: Thu, 08 Dec 2022 11:04:13 -0800 From: rjmcmahon To: Sebastian Moeller Cc: rjmcmahon via Make-wifi-fast , =?UTF-8?Q?Dave_T=C3=A4ht?= , Rpm , libreqos , Dave Taht via Starlink , bloat In-Reply-To: <7E221EFE-5094-437E-811A-B98AF60266A8@gmx.de> References: <9D0AC7EA-5EF2-45CE-9455-6A9B0374189E@gmx.de> <7E221EFE-5094-437E-811A-B98AF60266A8@gmx.de> Message-ID: <4e8ee21b1a69fba9c61366f6055fbc13@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast 2016 & crusader X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2022 19:04:14 -0000 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 >> Subject: Re: [Make-wifi-fast] [Rpm] make-wifi-fast 2016 & crusader >> Date: December 8, 2022 at 11:15:12 GMT+1 >> To: rjmcmahon >> Cc: rjmcmahon via Make-wifi-fast >> , Dave Täht >> , Rpm , libreqos >> , Dave Taht via Starlink >> , bloat >> >> Hi Bob, >> >> thanks for the detailed response. >> >> >>> On Dec 7, 2022, at 20:28, rjmcmahon 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