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 4882E3B29E; Fri, 6 Jan 2023 04:55:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1672998931; bh=CB/V92BkURjg8r1Gvu5NtLnVykG5APSt7vZMajTYBeU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=qTr+PIpdv72tJ/TeVRuYkusGtOYJC3q2RjX24WvxR9as3SPer9PAlhlFF0iuNK7pT lKbURfp9fq0JELZU+s0PfeVtslCEtHi5vo/3nAtcvx0ScX5mCWIqWaSV42wEAzp3Qn YBvRNeTLODsUE/fXdgOh7/YaxrkPjM2UnGm1yzAmoJmoT/7BEwGS0CiM1Fm5zofhWo SKjTMFuj9EyQHYYoY5LBieiRrb9FbN1U/HaK/QgBwqrQTH/4ZRYPn52GzWZJd+2LaK wqNpVSmImZO+nsCzcclDE2Q7pnGLOGfZRqP5+x8qpR5u50/s0dG3X5seaFV/wjmtPy 2Dw2cLraMvZPg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlf4c-1oV12f2jSs-00imaq; Fri, 06 Jan 2023 10:55:31 +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: <251832186E514080B5F1CF858F09A5ED@SRA6> Date: Fri, 6 Jan 2023 10:55:29 +0100 Cc: rjmcmahon , IETF IPPM WG , jf@jonathanfoulkes.com, libreqos , Cake List , Rpm , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <938DFCC0-F81F-4150-A274-FAFFB0E5C081@gmx.de> References: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> <305203F9-4875-4A7F-939E-B54E64AA060A@gmx.de> <251832186E514080B5F1CF858F09A5ED@SRA6> To: Dick Roy X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:blqiartkW8ODlq1gVqHA32hIHwsEY6zjzlTxIAmN6E8vLKcKHAO PMlqlQPADJC0CjDnuvdSq5BLna2mmGmSwEhS0ipXt2ZsuRUnjVEYi/Zqu7HwULNvMCchgSU EyNBA46S2GTxXG8N+UqFp+1G+Qxr3KDuecEeTt7d97QvMdkwlp6smyf9PmFhPsRK30Nq/FH R4w8Ll6R4H4LBSYVI63KQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:iJwkXyxAVjw=;53QxBx58Nu5p5AyTmWn/nKmIAkA LD91fuRiKzPqNA+pfBFkeKdVfw4VDwMNUZcVYpJgfsqlDbjeXoxQN/Uz3D/gdWfJsujQzpSwM k6V3WmbrNgZLrhCxLIkp2/WqJJ+4eHsKuRFJ4xldd30RFIbUhiYsfPdWaFPfDO1MMTG5sdE4y gFLnmuNRdvkqQpLQCZQYFvhFQQDLtqOuO4L9c9TnZvPdzwkgmoh/naG/A4rV+lGszTyRq80PI i2FBgjpTXo2Nnpq1axRm7LEZqUtZMtspWb0kjXZHfb/DfIcWX+iokJCqDz2morRZ1HqeX7dcC Uf2Z//NgUBMIfO9YeCTf38gRAF4UAKbvsCrinJ9y3y8bcUKT+HqwAuDiPeAuH/3uwKugj8N+y cbCT1D+010m8F92oDTpyjp0H40Ncf4Ke9SEQ/WfXOQrGvRosxEmtu8W6KYYTJz98j6kjlyR1y ZTzKCFLbEizYiCp3gcdN0LoJEam+SzdFuPXFygrlslZwRLoI6ZH6RbYEOnLJqVjRnHJk4GSgW MzOgmYmgCxaHdrxmq17RI8b/1DbLA+8gUNh0gstuY/A3+Fg7LfEhs+pY3+uAJ1I7K02gb2AJq G8Wq+tiY6fP7kzMrVC/o++Jm3SVsrDJUXjkTttJ/BbatkTYDZzm55QuHedr3Gl44AV2z2Imm9 U7o0x342R7uvkzJowqjpxtpMcWxo4PgZ0jMoBqligmAp0XnX63UA237k5GRarnPmw+eXoGO7E AWp2dwlv6EZFKpV5kpupHUN7/hLdSLKfV7asAWGsv7SSRHQlIHtoRLswlOu/pfB2c5Tm2NSV4 RJlQ0WPg6624EsmXrSadEPVur2OhOIfx/RRuQAHt+//UEYGj5LSOIep38/uSxIABtszYrfvqK 9w3rV2MKqWXvv11WJIFysiVDT80G6Rg7CoiDobnou1j/RrxMfd37/isPJdioq11Xz7GTTW2OQ CLyzSDAwMtAEjt1qe0mWWoHTFQg= Subject: Re: [Bloat] [Starlink] [Rpm] the grinch meets cloudflare'schristmas 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: Fri, 06 Jan 2023 09:55:42 -0000 Hi RR, > On Jan 6, 2023, at 01:30, Dick Roy wrote: >=20 > =20 > =20 > -----Original Message----- > From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On = Behalf Of Sebastian Moeller via Starlink > Sent: Thursday, January 5, 2023 3:12 AM > To: rjmcmahon > Cc: Dave Taht via Starlink; IETF IPPM WG; jf@jonathanfoulkes.com; = libreqos; Cake List; Rpm; bloat > Subject: Re: [Starlink] [Bloat] [Rpm] the grinch meets = cloudflare'schristmas present > =20 > Hi Bob, > =20 > =20 > > 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. > =20 > [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 ;) > [RR] I hope that this not true, however I am not doubting your = assertion! J=20 [SM2] Yes, not my preference either way, but it is hard to = overcome common usage... langauge sort of growth organically with the = occasional illogical side routes. > The capacity of a channel of bandwidth W (in its simplest form) is = well-known to be: > =20 > C =3D W*log2(1 + P/N)in units of bits/sec > =20 > There is no such thing generally as =E2=80=9Cmaximal capacity=E2=80=9D, = only =E2=80=9Ccapacity as a function of the parameters of the channel P, = N, and W=E2=80=9D which turns out to be the =E2=80=9Cmaximum error-free = (very important!) rate of information transfer=E2=80=9D given the power = (P) of the transmission and the power (N) of the noise in that channel = of bandwidth W.=20 [SM2] Mmmh, I thought that in telecommunications nobody aims for = error-free, but only for "acceptable" levels of errors? > 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... > [RR] As I recall the old analog modem days, modems were =E2=80=9Clabeled= =E2=80=9D by their achievable data rates, e.g. =E2=80=9Cthis is a 14.4 = kbps modem=E2=80=9D and the notion of achieving channel capacity was = quite well-known in that people actually realized that at 56 kbps, = modems were nearly at the capacity of those mile-long twisted-pair = copper wires to the CO with 3kHz bandwidth low-pass filters on the end = and they could stop trying to build faster ones J [SM] But IIRC 56K modems did not achieve this rate in both = directions? So either something like 40/48 or 56/33, so at least in the = V.90/V.92 class of 56K modems things already had become murky. > Personally I try to use rate instead of speed or bandwidth, but I note = that I occasionally fail without even noticing it. > =20 > 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 ;) > [RR] Again, transit time is only one component of latency, and one = that could be accounted for by simply stating the =E2=80=9Cminimal = achievable latency=E2=80=9D for any given channel is the transit time of = the information. Information simply can not flow faster than the speed = of light in this universe as we understand it today, so EVERY = communication channel has a non-zero transit time from source to = destination. J Comparing latency to =E2=80=9Cspeed of transmission=E2=80=9D= is just not useful IMO for just this reason. IMO, a more useful concept = of latency is the excess transit time over the theoretical minimum that = results from all the real-world =E2=80=9Cinterruptions=E2=80=9D in the = transmission path(s) including things like regeneration of optical = signals in long cables, switching of network layer protocols in gateways = (header manipulation above layer 4), and yes, of course, buffering in = switches and routers J These are things that can be =E2=80=9Cminimized=E2= =80=9D by appropriate system design (the topic of these threads = actually!). The only way to decrease transit time is to =E2=80=9Cgo = wireless everywhere, eliminate our atmosphere, and then get physically = closer to each other=E2=80=9D! J Like it or not, we live in a = Lorentz-ian space-time continuum also know as =E2=80=9Cour world=E2=80=9D = J [SM2] Pragmatically I think splitting delay into static and = variable components gets the most bang for the buck, the static delay = includes transit time, but also unavoidable queueing delay on the way = (signal refresh, or being moved from one interface to another in a = router), while the dynamic delay is the one that varies with a number of = external factors like own rate, others rates over shared links, variable = rate over links like LTE... So far "speedtests" typically only measured = "idle" latency which approximates the static delay, while for most = applications static delay can be worked around while changes in the = variable delay cause problems (if these changes are fast enough, very = slow changes can be adapted to just as well as truly static delay). Regards Sebastian > =20 > Cheers, >=20 > RR=20 > =20 > =20 > Regards > Sebastian > =20 > =20 > =20 > >=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 > =20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink