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 8D1263B29E; Wed, 7 Dec 2022 14:28:44 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 942121B321; Wed, 7 Dec 2022 11:28:43 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 942121B321 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1670441323; bh=S9WRNaP5kcfKNmVePD4Yt8T5KhDJXXAmOGJDfMj3+Zg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FTObTMt/Pxoj6KTE26NUQ3Sqs0oHo/gnk2mRYkM5DI9L26vjvD3oDboAl5Hg62BjU emDpiORalM2yvL8ehQXxL8VWw5etunP3rZbBAEI1ouL+rCvq652TtNFVTIxL/bSk1e 5TjStRexJwW2h1CyvGnvLcIA7jxYoghXKIcSdqNw= MIME-Version: 1.0 Date: Wed, 07 Dec 2022 11:28:43 -0800 From: rjmcmahon To: Sebastian Moeller Cc: rjmcmahon via Make-wifi-fast , Dave Taht , Rpm , libreqos , Dave Taht via Starlink , bloat In-Reply-To: <566AC2D7-FB33-4924-9B21-BE9A8476E0B3@gmx.de> References: <566AC2D7-FB33-4924-9B21-BE9A8476E0B3@gmx.de> Message-ID: X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 11 Dec 2022 08:24:12 -0500 Subject: Re: [Bloat] [Make-wifi-fast] [Rpm] make-wifi-fast 2016 & crusader X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2022 19:28:44 -0000 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 > 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@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/rpm >> >> ------------------------- >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.