[Rpm] [Starlink] [Bloat] the grinch meets cloudflare'schristmas present

Fri Jan 6 04:55:29 EST 2023

Hi RR,

> On Jan 6, 2023, at 01:30, Dick Roy <dickroy at alum.mit.edu> wrote:
> 
>  
>  
> -----Original Message-----
> From: Starlink [mailto:starlink-bounces at 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 at jonathanfoulkes.com; libreqos; Cake List; Rpm; bloat
> Subject: Re: [Starlink] [Bloat] [Rpm] the grinch meets cloudflare'schristmas present
>  
> Hi Bob,
>  
>  
> > On Jan 4, 2023, at 21:02, rjmcmahon via Bloat <bloat at lists.bufferbloat.net> wrote:
> > 
> > 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 ;)

> [RR] I hope that this not true, however I am not doubting your assertion! J 

	[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:
>  
> C = W*log2(1 + P/N)in units of bits/sec
>  
> There is no such thing generally as “maximal capacity”, only “capacity as a function of the parameters of the channel P, N, and W” which turns out to be the “maximum error-free (very important!) rate of information transfer” given the power (P) of the transmission and the power (N) of the noise in that channel of bandwidth W. 

	[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 “labeled” by their achievable data rates, e.g. “this is a 14.4 kbps modem” 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.
>  
> 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 “minimal achievable latency” 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 “speed of transmission” 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 “interruptions” 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 “minimized” by appropriate system design (the topic of these threads actually!).  The only way to decrease transit time is to “go wireless everywhere, eliminate our atmosphere, and then get physically closer to each other”! J Like it or not, we live in a Lorentz-ian space-time continuum also know as “our world” 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

>  
> Cheers,
> 
> RR 
>  
>  
> Regards
>       Sebastian
>  
>  
>  
> > 
> > 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 <rpm at lists.bufferbloat.net> 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-6981366665607352320-FXtz
> >>> Dave Täht CEO, TekLibre, LLC
> >>> <image.png><tcp_nup-2023-01-04T090937.211620.LTE.flent.gz>_______________________________________________
> >>> Rpm mailing list
> >>> Rpm at lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/rpm
> >> _______________________________________________
> >> Rpm mailing list
> >> Rpm at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/rpm
> > _______________________________________________
> > Bloat mailing list
> > Bloat at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>  
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink