[Starlink] [Rpm] the grinch meets cloudflare's christmas present

Thu Jan 5 19:01:15 EST 2023

Hi Sebastian,

See below 

-----Original Message-----
From: Sebastian Moeller [mailto:moeller0 at gmx.de] 
Sent: Thursday, January 5, 2023 3:26 AM
To: Dick Roy
Cc: Dave Collier-Brown; starlink at lists.bufferbloat.net
Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
present

Hi RR,

> On Jan 5, 2023, at 04:11, Dick Roy via Starlink
<starlink at lists.bufferbloat.net> wrote:

> 

>  

>  

> From: Starlink [mailto:starlink-bounces at lists.bufferbloat.net] On Behalf
Of Dave Collier-Brown via Starlink

> Sent: Wednesday, January 4, 2023 6:48 PM

> To: starlink at lists.bufferbloat.net

> Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
present

>  

> I think using "speed" for "the inverse of delay" is pretty normal English,
if technically erroneous when speaking nerd or physicist.

> 

> [RR] Ive not heard of that usage before.  The units arent commensurate
either. 

> 

> Using it for volume? Arguably more like fraudulent...

> 

> [RR] I dont think that was Bobs intent.  I think load volume was meant
to be a metaphor for number of bits/bytes being transported (by the
semi).  

> 

> That said, arent users these days educated on gigs which they
intuitively understand to be Gigabits per second (or Gbps)?  Oddly enough,
that is an expression of data/information/communication rate in the
appropriate units with the nominal technically correct meaning.  

      [SM] Gigs would have the following confounds if used without a proper
definition:

a) base10 or base2^10?

b) giga-what? Bit or Byte

c) Volume or capacity

d) if capacity, minimal, average, or maximal?

I note (again, sorry to sound like a broken record) that the national
regulatory agency for networks (Bundes-Netzagentur, short BNetzA) in Germany
has some detailed instructions about what information ISPs need to supply to
their potential customers pre-sale (see
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekom
munikation/Unternehmen_Institutionen/Anbieterpflichten/Kundenschutz/Transpar
enzmaßnahmen/Instruction_for_drawing_up_PIS.pdf?__blob=publicationFile&v=1)
where the headlines talk correctly about "data transmission rates" but in
the text they occasionally fall back to "speed". They also state: "Data
transmission rates must be given in megabits per second (Mbit/s)."

This is both in response to our "speed" discussion, but also one potential
way to clarify b) c) and d) above... given that is official this probably
also answers a) (base10 otherwise the text would be "Data transmission rates
must be given in mebibits per second (Mibit/s).")

[RR] My reference to gigs was to the ads out nowadays from AT&T about
becoming Gagillionaires (Yes, I am Jurgous. 
 We know!) that now have gig
speed wireless from AT&T so they can play all kinds of VR games. :-) That
said, not sure why BNetzA mandates a particular unit for information rates,
but thats their prerogative I guess.  Given that the fundamental unit of
information is the answer to a YES/NO question (aka a bit), it makes sense
to measure information in bits (although trits or any other higher order
concept could be used as long as the system accounted for fractions
thereof:-)) (and sets of bits (aka bytes or really octets) because of
ancient computer arcitectures:-)).  Since we have pretty much settled on the
SI second as the accepted unit of time (and multiples thereof e.g. msec,
usec, nsec, etc.), it makes sense to measure information flow in bits/sec or
some multiples thereof such as Gbps, Mbps, Kbps, etc. and their byte (really
octet) versions GBps, MBps, KBps, etc.. Not sure why BNetzA mandates ONLY
one of these, but whatever 
 :-)

As for capacity, remember capacity is not something that is measured. It is
a fundamental property (an information rate!) of a communication channel
which has no other attributes such as minimal, average, or maximal (unless
one is talking about time-varying channels and is wanting to characterize
the capacity of the channel over time, but thats another story).  As such,
comparing volume and capacity is comparing apples and oranges; one is a size
of something (e.g. number of megabytes) and the other is a rate (e.g. MBps)
so I am not sure what Volume or capacity really means. I suspect the
concept you may be looking for is achievable rate rather than capacity.
Achievable rate IS something that is measureable, and varies with load when
channels are shared, etc..  Loosely speaking, achievable rate is always less
than or equal to the capacity of a channel. 

HNY,

RR

--Sebastian

> 

> RR

> 

> --dave

> 

> On 1/4/23 18:54, Bruce Perens via Starlink wrote:

>> On the other hand, we would like to be comprehensible to normal users,
especially when we want them to press their providers to deal with
bufferbloat. Differences like speed and rate would go right over their
heads.

>>  

>> On Wed, Jan 4, 2023 at 1:16 PM Ulrich Speidel via Starlink
<starlink at lists.bufferbloat.net> wrote:

>>> 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 at auckland.ac.nz

>>> http://www.cs.auckland.ac.nz/~ulrich/

>>> **************************************************************** 

>>> From: Starlink <starlink-bounces at lists.bufferbloat.net> on behalf of
rjmcmahon via Starlink <starlink at lists.bufferbloat.net>

>>> Sent: Thursday, January 5, 2023 9:02 AM

>>> To: jf at jonathanfoulkes.com <jf at jonathanfoulkes.com>

>>> Cc: Cake List <cake at lists.bufferbloat.net>; IETF IPPM WG
<ippm at ietf.org>; libreqos <libreqos at lists.bufferbloat.net>; Dave Taht via
Starlink <starlink at lists.bufferbloat.net>; Rpm <rpm at lists.bufferbloat.net>;
bloat <bloat at lists.bufferbloat.net>

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

>>> _______________________________________________

>>> Starlink mailing list

>>> Starlink at lists.bufferbloat.net

>>> https://lists.bufferbloat.net/listinfo/starlink

>>> _______________________________________________

>>> Starlink mailing list

>>> Starlink at lists.bufferbloat.net

>>> https://lists.bufferbloat.net/listinfo/starlink

>> 

>>  

>> -- 

>> Bruce Perens K6BP

>> 

>> 

>> 

>> _______________________________________________

>> Starlink mailing list

>> Starlink at lists.bufferbloat.net

>> https://lists.bufferbloat.net/listinfo/starlink

> -- 

> David Collier-Brown,         | Always do right. This will gratify

> System Programmer and Author | some people and astonish the rest

> dave.collier-brown at indexexchange.com |              -- Mark Twain

>  

> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including
any and all attachments, contains confidential information intended only for
the person(s) to whom it is addressed. Any dissemination, distribution,
copying or disclosure is strictly prohibited and is not a waiver of
confidentiality. If you have received this telecommunication in error,
please notify the sender immediately by return electronic mail and delete
the message from your inbox and deleted items folders. This
telecommunication does not constitute an express or implied agreement to
conduct transactions by electronic means, nor does it constitute a contract
offer, a contract amendment or an acceptance of a contract offer. Contract
terms contained in this telecommunication are subject to legal review and
the completion of formal documentation and are not binding until same is
confirmed in writing and has been signed by an authorized signatory.

> 

> _______________________________________________

> 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/starlink/attachments/20230105/34079a4e/attachment-0001.html>