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 C97A53B29D for ; Thu, 5 Jan 2023 01:06:20 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id C795C1B258; Wed, 4 Jan 2023 22:06:19 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com C795C1B258 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1672898779; bh=KBnk4BsEwpTzigj/kY0tDRKyvvMkj3bBgruwG2G8JCc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FMSfkf44SJ0HiZLxTvGXOthfdO234GciTy56zgKbUxSegVpbFMe1egQpqgOPVwOge HO17TNP5Bkr2NP+FpJ6GUhPDZCLcFscH0zo+BR5YwE3EWGZpPK/lU4m5Yh5fB0dl1e HyL6PaerJ9okYJ4cPDNAIzwQwVhS7qyP1FKFessI= MIME-Version: 1.0 Date: Wed, 04 Jan 2023 22:06:19 -0800 From: rjmcmahon To: dickroy@alum.mit.edu Cc: 'Ulrich Speidel' , jf@jonathanfoulkes.com, 'bloat' In-Reply-To: References: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> Message-ID: <62a9b2d0157b78261567d809a4e7a787@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] [Starlink] [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 06:06:20 -0000 Well, from an iperf 2 perspective channel capacity of a TCP socket is information/time. I think that's also more or less how Shannon defined it. I don't think channel capacity matters if it's measured or somehow otherwise computed, or maybe never even known. It exists on its own merits regardless ;) "Shannon's Theorem gives an upper bound to the capacity of a link, in bits per second (bps), as a function of the available bandwidth and the signal-to-noise ratio of the link." "the channel capacity of a given channel is the highest information rate (in units of information per unit time) that can be achieved with arbitrarily small error probability." https://en.wikipedia.org/wiki/Channel_capacity Then, there is latency which is delay in units time. So why do we use the term "speed" when we're talking about delay? I find it similar to the speed of causality except applied to us mere mortal computer programmers. Our programs block while waiting on those delays. Network engineers reducing those delays in turn can increase the speed of the programmer's objectives. So speed here really is the speed of a coupled distributed computer system. Never to exceed the speed of light but we should try to get there anyway. Bob > OK, so now we are all showing our age! And yes, the lexicon has > become really muddied … generally the result of someone who doesn't > know (and thinking they do J), speaking the loudest and the longest > and whaddaya know, all of a sudden we have "speed tests" and "capacity > tests", when really what is happening is that > "data/information/communication rate" is being "measured/estimated". > Neither "speed" nor "capacity" is being "tested". Oh, for the good ole > days when … J > > ------------------------- > > From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On > Behalf Of Ulrich Speidel via Starlink > Sent: Wednesday, January 4, 2023 1:17 PM > To: jf@jonathanfoulkes.com; rjmcmahon > Cc: Dave Taht via Starlink; bloat > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas > present > > The use of the term "speed" in communications used to be restricted to > the speed of light (or whatever propagation speed one happened to be > dealing with. Everything else was a "rate". Maybe I'm old-fashioned > but I think talking about "speed tests" muddies the waters rather a > lot. > > -- > **************************************************************** > Dr. Ulrich Speidel > > Department of Computer Science > > Room 303S.594 > Ph: (+64-9)-373-7599 ext. 85282 > > The University of Auckland > u.speidel@auckland.ac.nz > http://www.cs.auckland.ac.nz/~ulrich/ [1] > **************************************************************** > > ------------------------- > > From: Starlink on behalf of > rjmcmahon via Starlink > Sent: Thursday, January 5, 2023 9:02 AM > To: jf@jonathanfoulkes.com > Cc: Cake List ; IETF IPPM WG > ; libreqos ; Dave Taht > via Starlink ; Rpm > ; bloat > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas > present > > 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. > > 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't deliver >> reliable low-latency unless you shave a good bit off the targets. My >> local loop is pretty congested. >> >> Here's 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/ [2] >>> >>> 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-6981366665607352320-FXtz >>> Dave Täht 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 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > > Links: > ------ > [1] http://www.cs.auckland.ac.nz/%7Eulrich/ > [2] https://speed.cloudflare.com