From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8182F3B2A4; Mon, 9 Jan 2023 14:47:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1673293649; bh=GCQcIyTwKcQrcAPSk8Z8v59Ypy7ixPIB7ffxTeuTDUI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=lta+ex7FIcj/CamUdJIYKGYvlgXvHgKIvJIsmtSZNa/GjZ5YoJBBZX4qvifZf7iPU JLnDxgMszbEiWxhdplrZNTnz5ELMvXrmOFDSwhx/oN53bjVzlIF9TRIrDY1yScnt9g DvtOGfxVv3lIvxmmn68JBMQyQWBpug7IYuQ0i0bCbnBl2pa+VwCP1TaInBdRU83g1a TC3YQpMlC8hTBAUVj3x8YCGTB2m83jofcvbAfSpfnFFfOTGo7KDda8Re/HU5WObEnw Gj2GaSitZ7W3E+mVJliV3Zh7aGlEkQx0b88Kr3Kb/s1PYC4SyM6Ip3oqfieHvnGFvI 0wCAY31lsm+vA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.116.104.26]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2V4J-1om78o0RMl-013rr5; Mon, 09 Jan 2023 20:47:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: <412c00f23a6cfef61ecbf0fd9b6f3069@rjmcmahon.com> Date: Mon, 9 Jan 2023 20:47:27 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Dave Taht via Starlink , mike.reynolds@netforecast.com, libreqos , "David P. Reed" , Rpm , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <80EE4A0F-410A-4DCA-9074-22D44713166B@gmx.de> References: <1672786712.106922180@apps.rackspace.com> <412c00f23a6cfef61ecbf0fd9b6f3069@rjmcmahon.com> To: rjmcmahon X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:0Jy+Dv28WA/ON1OMJsq1RlWCvPIhv6TKL174NXlWnfrVxjLffTU dCg6Zeyg/F33CKcnpjuFwegO5J1e2XmBPCHczTcKngyjFG9UHjkXVAZ0ZXr6vKdl9X7a19b X8+4GryezpCmbiqDavjCvjZBaMhccFpAagMcsddAR4Mahug6iIq/gB8Fhk+QKrT1s7lxpvL lJmHj1AVVHfWHVybZbiQQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:TLTR09dWGIU=;ouIIG2C72ihcTt2UJHfnpPtuRQF PuAq78VIZvd4BJFlB/2h8zICy4E+nOIw7q2hRc8h3FK42j8iGSBw6urynTdS/GjBr3iQymAD2 6/klC6VN8JJa8br8KCMxhzuCsqXpxbBT2U//ZKFiEPsVKYKNUCgRdRzs1akgIFmAVBivwZPuJ SEW3ZGYqmKYDBTGib5rb+HP64HhVU5z45YWZ1lbaZy99wI9GTlLjw8nWdiqMw4Jpi3aJTbeh3 QDtUHj3KX+6bjEqXIHqIdHsSq31SXM37tSTQTDz7NLwyVSLxcHrJw0odpbcyHL4a8Bx5OSW5T DhCIvbxpy+NG3pD7Sn8Vjymy6s79DEQxxYXky5+0RQevxYwZO1jWCLuofYbwL0emSZ0j/ErRX L3+wlgMRFUAPJ1pgXghARXfPe3PSUTNmu0d0ZMOhw+valnMuNGzYfNw5Nsy34qUqeWLmlsURj z9sogYw8kAnUjEzU06zFbm9Skkl40GnKWlXFPSR4Jk6rquX8aLok8fyTWdFRAMFa8dCFNLcuK iJ3DSLthQYWwu5HuqEdXRmZnSvmOMGn6+lodqRcq6bE51XpBkFcyIVcss6QUHixnX34tPhAiF fM1kIYkQEo+dKuS35yl9vwH1XZNEA5gqlTrJGc0ctdvWR7t8hu1t4+kxmaPMTL6c8LAxpjxjQ Sy6cpr/vZjVuhCUtLpfwpqCbQHwI9RwKSEXiqMZiu7cpWo8UCaJ0Scn3TMPYxGXdkWW5Gfeb7 e1ntsvdX4OoLWLs9TgPBVWl5J85zipg/q2anmG/4aJfwcVIFN5acJTIohYIOmNPYuMsQpIBdC bMXPo2TN5nVmvZTjL824ebjgGVgLZlCrIq6/7QupQsX1h+MTTh+5ieV13FxWC8AMXkW23Se0S LbbVrI5OQaDO1quAOpRdtdU88B5leqXAsadBimoYLSs0Lhqh3S8Z8AKCaUUcSiRnrMtWom91p HmwD2w== Subject: Re: [Starlink] [Rpm] Researchers Seeking Probe Volunteers in USA X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2023 19:47:38 -0000 Hi Bib, > On Jan 9, 2023, at 20:13, rjmcmahon via Starlink = wrote: >=20 > My biggest barrier is the lack of clock sync by the devices, i.e. very = limited support for PTP in data centers and in end devices. This limits = the ability to measure one way delays (OWD) and most assume that OWD is = 1/2 and RTT which typically is a mistake. We know this intuitively with = airplane flight times or even car commute times where the one way time = is not 1/2 a round trip time. Google maps & directions provide a time = estimate for the one way link. It doesn't compute a round trip and = divide by two. >=20 > For those that can get clock sync working, the iperf 2 --trip-times = options is useful. [SM] +1; and yet even with unsynchronized clocks one can try to = measure how latency changes under load and that can be done per = direction. Sure this is far inferior to real reliably measured OWDs, but = if life/the internet deals you lemons.... >=20 > --trip-times > enable the measurement of end to end write to read latencies (client = and server clocks must be synchronized) [SM] Sweet! Regards Sebastian >=20 > Bob >> I have many kvetches about the new latency under load tests being >> designed and distributed over the past year. I am delighted! that = they >> are happening, but most really need third party evaluation, and >> calibration, and a solid explanation of what network pathologies they >> do and don't cover. Also a RED team attitude towards them, as well as >> thinking hard about what you are not measuring (operations research). >> I actually rather love the new cloudflare speedtest, because it tests >> a single TCP connection, rather than dozens, and at the same time = folk >> are complaining that it doesn't find the actual "speed!". yet... the >> test itself more closely emulates a user experience than = speedtest.net >> does. I am personally pretty convinced that the fewer numbers of = flows >> that a web page opens improves the likelihood of a good user >> experience, but lack data on it. >> To try to tackle the evaluation and calibration part, I've reached = out >> to all the new test designers in the hope that we could get together >> and produce a report of what each new test is actually doing. I've >> tweeted, linked in, emailed, and spammed every measurement list I = know >> of, and only to some response, please reach out to other test = designer >> folks and have them join the rpm email list? >> My principal kvetches in the new tests so far are: >> 0) None of the tests last long enough. >> Ideally there should be a mode where they at least run to "time of >> first loss", or periodically, just run longer than the >> industry-stupid^H^H^H^H^H^Hstandard 20 seconds. There be dragons >> there! It's really bad science to optimize the internet for 20 >> seconds. It's like optimizing a car, to handle well, for just 20 >> seconds. >> 1) Not testing up + down + ping at the same time >> None of the new tests actually test the same thing that the infamous >> rrul test does - all the others still test up, then down, and ping. = It >> was/remains my hope that the simpler parts of the flent test suite - >> such as the tcp_up_squarewave tests, the rrul test, and the rtt_fair >> tests would provide calibration to the test designers. >> we've got zillions of flent results in the archive published here: >> https://blog.cerowrt.org/post/found_in_flent/ >> ps. Misinformation about iperf 2 impacts my ability to do this. >=20 >> The new tests have all added up + ping and down + ping, but not up + >> down + ping. Why?? >> The behaviors of what happens in that case are really non-intuitive, = I >> know, but... it's just one more phase to add to any one of those new >> tests. I'd be deliriously happy if someone(s) new to the field >> started doing that, even optionally, and boggled at how it defeated >> their assumptions. >> Among other things that would show... >> It's the home router industry's dirty secret than darn few "gigabit" >> home routers can actually forward in both directions at a gigabit. = I'd >> like to smash that perception thoroughly, but given our starting = point >> is a gigabit router was a "gigabit switch" - and historically been >> something that couldn't even forward at 200Mbit - we have a long way >> to go there. >> Only in the past year have non-x86 home routers appeared that could >> actually do a gbit in both directions. >> 2) Few are actually testing within-stream latency >> Apple's rpm project is making a stab in that direction. It looks >> highly likely, that with a little more work, crusader and >> go-responsiveness can finally start sampling the tcp RTT, loss and >> markings, more directly. As for the rest... sampling TCP_INFO on >> windows, and Linux, at least, always appeared simple to me, but I'm >> discovering how hard it is by delving deep into the rust behind >> crusader. >> the goresponsiveness thing is also IMHO running WAY too many streams >> at the same time, I guess motivated by an attempt to have the test >> complete quickly? >> B) To try and tackle the validation problem:ps. Misinformation about = iperf 2 impacts my ability to do this. >=20 >> In the libreqos.io project we've established a testbed where tests = can >> be plunked through various ISP plan network emulations. It's here: >> https://payne.taht.net (run bandwidth test for what's currently = hooked >> up) >> We could rather use an AS number and at least a ipv4/24 and ipv6/48 = to >> leverage with that, so I don't have to nat the various emulations. >> (and funding, anyone got funding?) Or, as the code is GPLv2 licensed, >> to see more test designers setup a testbed like this to calibrate >> their own stuff. >> Presently we're able to test: >> flent >> netperf >> iperf2 >> iperf3 >> speedtest-cli >> crusader >> the broadband forum udp based test: >> https://github.com/BroadbandForum/obudpst >> trexx >> There's also a virtual machine setup that we can remotely drive a web >> browser from (but I didn't want to nat the results to the world) to >> test other web services. >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink