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 44E5D3B29D; Thu, 5 Jan 2023 06:11:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1672917105; bh=vjKJAef5TPVXcnEnIG0BnSexUb9LltDSMSN/N8dg4uo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P4/5aimbpYj5yafhH0ACXoPKynwZO3OGrnLxxO/MhioOGFcf/WlubFStbbaWk7dMO OEe2E9100NSCIyL0k8N1vaptcoH+7FtBi7ABrYvmmYx6U8ps07uOf76PvzmDDWUbuR /+M1Dbu0BKtDSM6dYjwEL+TTp7E10B6F/i/Qen4gWtNnFdQgegxVKcJgRKl0p2bwOy iaQ0nS1smW6v9iDvFauTnex7pwV/QG3yRIkzv9B2DFp5gnadVDh2NYemA/3m/k6u4v /yrktZbJXtaYhweE/80Zu1NtooT8WepKkOXR/zFZ/p8csOuMPWolzkgOET72JsSl4c IxiW/hrhfYCxA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtwUm-1owpmX0uC4-00uHe6; Thu, 05 Jan 2023 12:11:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 5 Jan 2023 12:11:42 +0100 Cc: jf@jonathanfoulkes.com, Cake List , IETF IPPM WG , libreqos , Dave Taht via Starlink , Rpm , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <305203F9-4875-4A7F-939E-B54E64AA060A@gmx.de> References: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> To: rjmcmahon X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:jGJtoRkFjUgOZugLKJd89lSoAUNufog31h/ZWuJ2oYRTra5m3Av 1dCpCY4EccSGPTVM2DsJo/rsEuOEaQ33TEGVtgsEP+uf1hKReE5gtLgls1m26/cikNL8xOg 4cFGw63EVMnWpmmO6pbS5tnwNNd5/IPTusOLplwzGlQU8FUerOh38sCWaNnG7ulFomt9uFl iucavCaDm26WDInSGhZbQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:YJTXohHSOZo=;CW6Dh8XQ0ecSPvzpO99qIpYyVe7 Mvrqf0UojvLXCf6nDL24y0NRHdhnbdgpq46T6AR2oYsotPSyP+bA35IxNbqPF1xJLQJB82YU3 mqk5+SyzsH4syRnSR9Uy/E8pO7acHufIAMGuy29E6y0Xeu9wnO6z7L+mkbmBH1PmoUVB/Ph5X IKtvta9A2UcbncVEw5oMU16r5ZeI3GR5ajPS8qbUQnQTnjc0PBFEnyS36b1NfRWInOK14MY1G +AMJCzCw75jDF/nmIP84QoQP4gXlahKKznBiC8n9sQsfdrxOAAqOCFxBWCEc1IqK755dF7iPt NqmOfroeQZQo71q7UsNvAGE7yJLqlAsXr0wTJ42pmq2YP09g/WhJ9AlKKEQ2y+38YTvBSOs3L LrdFgoIOCFm+CO7gmUdatC9/1GRWcaO4SYb/uduovZU2UeHEhniQPwOM51bJXoL52eHw6Z3xl gDD4BjMZV5wzraxtb337eluJM71YsmuZzMt0hgFH4W0dbg1nIiN3c35y84hmWP4pMj7VjSxsD 5vgpHFd2yJFLS+EbE7MeUAc18qATlampBJLSKpMCMmrWzYg7DQgb6QSRfLZUT8vBnlZ9Os/b/ vpYwj+0gIMT7jwvZIHMM1Xceh+cHGw3GPrcvAo6t1FuSJhAoNay/C5XgqLx+hySfzmwmHWZEB tndT6yqpx+dCIF8ZHGFMJsqClEeTemq+HH/10hdnblZ/sBaHgkAgz6D0Ie2ysIkJQ+fIapkIK RO2aQTOo9FKq9bj2Pc4YLsiBNA4JhpvSkbgcO0Mzz6613ZquSiYcqV9SVwlF0RZ0MLuvAlcS8 1XyOYFhB1bclYAOaZulIJASLMxfLumQTPkRN3wxvr6poPVIrUm8vYfKHF9Y32tMv9wqK1DM0B 6e0GtFgTSYKKe0sd58s06Lj7pOgheKnNht2PYyB0emebiyJ7C4ljX7ki58U4AyzpEdPJ8fujn uDWhaw== Subject: Re: [Bloat] [Rpm] the grinch meets cloudflare's christmas present 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: Thu, 05 Jan 2023 11:11:53 -0000 Hi Bob, > On Jan 4, 2023, at 21:02, rjmcmahon via Bloat = wrote: >=20 > Curious to why people keep calling capacity tests speed tests? A semi = at 55 mph isn't faster than a porsche at 141 mph because its load volume = is larger. [SM] I am not sure whether answering the "why" is likely to = getting us closer to remedy the situation. IMHO we are unlikely to = change that just as we are unlikely to change the equally debatable use = of "bandwidth" as synonym for "maximal capacity"... These two ships have = sailed no matter how much shouting at clouds is going to happen ;) My theory about the way is, this is entirely marketing driven, both = device manufacturers/ISPs and end-users desire to keep things simple so = ideally a single number and a catchy name... "Speed" as in top-speed was = already a well known quantity for motor vehicles that consumers as a = group had accepted to correlate with price. Now purist will say that = "speed" is already well-defined as distance/time and "amount of data" is = not a viable distance measure (how many bits are there in a meter?), but = since when has marketing and the desire for simply single-number = "quality indicators" ever cared much for the complexities of the real = world? Also when remembering the old analog modem and ISDN days, at = that time additional capacity truly was my main desirable, so marketing = by max capacity was relevant to me independent of how this was called, I = would not be amazed if I was not alone with that view. I guess that = single measure and the wrong name simply stuck... Personally I try to use rate instead of speed or bandwidth, but I note = that I occasionally fail without even noticing it. Technically I agree that one way latency is more closely related to = "speed" as between any two end-points there is always a path the = information travels that has a "true" length, so speed could be defined = as network-path-length/OWD, but that would only be the average speed = over the path... I am not sure how informative or marketable this wuld = be for end-users though ;) Regards Sebastian >=20 > Bob >> HNY Dave and all the rest, >> Great to see yet another capacity test add latency metrics to the >> results. This one looks like a good start. >> Results from my Windstream DOCSIS 3.1 line (3.1 on download only, up >> is 3.0) Gigabit down / 35Mbps up provisioning. Using an IQrouter Pro >> (an i5 x86) with Cake set for 710/31 as this ISP can=E2=80=99t = deliver >> reliable low-latency unless you shave a good bit off the targets. My >> local loop is pretty congested. >> Here=E2=80=99s the latest Cloudflare test: >> And an Ookla test run just afterward: >> They are definitely both in the ballpark and correspond to other = tests >> run from the router itself or my (wired) MacBook Pro. >> Cheers, >> Jonathan >>> On Jan 4, 2023, at 12:26 PM, Dave Taht via Rpm = wrote: >>> Please try the new, the shiny, the really wonderful test here: >>> https://speed.cloudflare.com/ >>> I would really appreciate some independent verification of >>> measurements using this tool. In my brief experiments it appears - = as >>> all the commercial tools to date - to dramatically understate the >>> bufferbloat, on my LTE, (and my starlink terminal is out being >>> hacked^H^H^H^H^H^Hworked on, so I can't measure that) >>> My test of their test reports 223ms 5G latency under load , where >>> flent reports over 2seconds. See comparison attached. >>> My guess is that this otherwise lovely new tool, like too many, >>> doesn't run for long enough. Admittedly, most web objects (their >>> target market) are small, and so long as they remain small and not >>> heavily pipelined this test is a very good start... but I'm pretty >>> sure cloudflare is used for bigger uploads and downloads than that. >>> There's no way to change the test to run longer either. >>> I'd love to get some results from other networks (compared as usual = to >>> flent), especially ones with cake on it. I'd love to know if they >>> measured more minimum rtts that can be obtained with fq_codel or = cake, >>> correctly. >>> Love Always, >>> The Grinch >>> -- >>> This song goes out to all the folk that thought Stadia would work: >>> = https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665= 607352320-FXtz >>> Dave T=C3=A4ht CEO, TekLibre, LLC >>> = ________________= _______________________________ >>> Rpm mailing list >>> Rpm@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/rpm >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat