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

Thu Jan 5 19:30:31 EST 2023

-----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!
:-)  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. 

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 :-) 

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. :-) 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 :-)  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! :-) Like it or not, we live in a
Lorentz-ian space-time continuum also know as our world :-) 

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 cant deliver

>> reliable low-latency unless you shave a good bit off the targets. My

>> local loop is pretty congested.

>> Heres 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-698136666560
7352320-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20230105/f8cee952/attachment-0001.html>