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

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

[David Fernández]

When a user refers to "gigs" it can be also talking about the monthly
data cap volume in the cell phone or mobile subscription.

A user is mainly not aware of what can be done with the "gigs". You
understand what you get when you get minutes of phone calls or a
certain number of SMS, but "gigs" are consumed in a way the user
mostly does not understand. Sometimes it is translated to a volume of
WhatsApp messages, pictures, videos (in a certain resolution, DVD
quality, for example), so people understand a bit what they are paying
for.

Language is ambiguous. Data rate in bit/s is referred as communication
channel capacity by Shannon, not to speed, but speed in km/h is an
analogy for information "running" in bit/s that people maybe
understand better.

Then, there is the people that ask you how much a file "weights" to
refer to the amount of bytes it has, as if information has a kind of
inertial mass.

There is the technical language and then the non-technical people
language. Two worlds apart, sometimes.

Regards,

David

> Date: Wed, 4 Jan 2023 19:11:28 -0800
> From: "Dick Roy" <dickroy@alum.mit.edu>
> To: "'Dave Collier-Brown'" <dave.collier-Brown@indexexchange.com>
> Cc: <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
> 	present
> Message-ID: <15EBCC5BF2474AAB82C050259229B5FB@SRA6>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
>   _____
>
> From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
> Dave Collier-Brown via Starlink
> Sent: Wednesday, January 4, 2023 6:48 PM
> To: starlink@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] I’ve not heard of that usage before.  The units aren’t commensurate
> either.
>
> Using it for volume? Arguably more like fraudulent...
>
> [RR] I don’t think that was Bob’s intent.  I think “load volume” was meant
> to be a metaphor for “number of bits/bytes” being transported (“by the
> semi”).
>
> That said, aren’t 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.
>
> RR
>
> --dave
>

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

[Sebastian Moeller]

Hi RR,


> On Jan 6, 2023, at 01:01, Dick Roy <dickroy@alum.mit.edu> wrote:
> 
> Hi Sebastian,
>  
> See below …
>  
> -----Original Message-----
> From: Sebastian Moeller [mailto:moeller0@gmx.de] 
> Sent: Thursday, January 5, 2023 3:26 AM
> To: Dick Roy
> Cc: Dave Collier-Brown; starlink@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@lists.bufferbloat.net> wrote:
> > 
> >  
> >  
> > From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of Dave Collier-Brown via Starlink
> > Sent: Wednesday, January 4, 2023 6:48 PM
> > To: starlink@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] I’ve not heard of that usage before.  The units aren’t commensurate either. 
> > 
> > Using it for volume? Arguably more like fraudulent...
> > 
> > [RR] I don’t think that was Bob’s intent.  I think “load volume” was meant to be a metaphor for “number of bits/bytes” being transported (“by the semi”).  
> > 
> > That said, aren’t 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 (seehttps://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Anbieterpflichten/Kundenschutz/Transparenzmaß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. 

	[SM2] Ah, not being in the U.S. that campaign has completely evaded my attention.


> J That said, not sure why BNetzA mandates a particular unit for information rates, but that’s their prerogative I guess.

	[SM2] My bigger point was actually that they use the term "data transmission rates" instead of speed... But to your point the product information sheets are designed specifically to make it easy for consumers to compare different offers (for all values of consumer knowledge of networking and SI-prefixes) and requiring a single unit makes comparison simple and gives less leeway to play games. This BNetzA initiative basically removed the previous "up to XX Mbps" promise of ISPs and especially the interpretation that YY with YY << XX is still the contractually fine as "up to" implies not guarantee.


>  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 thereofJ) (and sets of bits (aka bytes or really octets) because of ancient computer arcitecturesJ).

	[SM2] I agree, but prefer this to be inherent in the term used, and "gigs" did not carry any of that information for me, but again I had not encountered the AT&T campaign...


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

	[SM2] Again I speculate that this is to allow easy comparison even by consumers that are not "fluent" in interpreting SI-prefixes and that might e.g. not know by heart whether Mb is larger or smaller than Gb, let alone why mB is not equal to Mb... this is a transparency measure foremost aimed at all end-customers (business contract do not fall under that regulation as far as I know).

> 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 that’s another story).

	[SM] On a shared medium (and let's face it head on sooner or later "internet-access" will become a shared medium) the capacity share each user can relay on is rarely static, most often ISPs oversubscribe links and use traffic shapers to limit the maximum capacity share a user can use, but that share is not guaranteed to be available. BNetzA went as far as defining three different data rates with different expected (temporal) availability as well as a (rather complicated) method how end-users can confirm whether ISPs actually deliver the promised rates.


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

	[SM] The term Gigs unlike e.g. Mb/s or Mbps (for Megabits per second) does not intuitively define whether time is taken into account, and over here mobile contracts typically come with a "high-speed Volume" after the consumption of which mobile links fall back to truly atrocious rates like 32Kbps, for these kind of contracts ISPs tend to primarily market the Volume (mostly in GB) and only mention the maximal data rates as secondary information.


> I suspect the concept you may be looking for is “achievable rate” rather than “capacity”.

	[SM2] Actually I always try to first calculate the theoretical upper limit of my links (which I then dub the link's "capacity") and I compare the actual measured rates with the theoretical limit... This works well enough for me, since the consumer links I use typically are dominated by a predictable traffic shaper on the ISP side...


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

	[SM2] Yepp, that is why I try to calculate a capacity estimate (and calculate the resulting throughput on different levels).

Regards
	Sebastian


>  
> 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@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@auckland.ac.nz
> >>> http://www.cs.auckland.ac.nz/~ulrich/
> >>> **************************************************************** 
> >>> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
> >>> Sent: Thursday, January 5, 2023 9:02 AM
> >>> To: jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
> >>> Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG <ippm@ietf.org>; libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>; bloat <bloat@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 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@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@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
> >>> _______________________________________________
> >>> Starlink mailing list
> >>> Starlink@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/starlink
> >> 
> >>  
> >> -- 
> >> Bruce Perens K6BP
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@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@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@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink

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

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 11785 bytes --]

Hi Sebastian,

 

See below …

 

-----Original Message-----
From: Sebastian Moeller [mailto:moeller0@gmx.de] 
Sent: Thursday, January 5, 2023 3:26 AM
To: Dick Roy
Cc: Dave Collier-Brown; starlink@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@lists.bufferbloat.net> wrote:

> 

>  

>  

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

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

> To: starlink@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] I’ve not heard of that usage before.  The units aren’t commensurate
either. 

> 

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

> 

> [RR] I don’t think that was Bob’s intent.  I think “load volume” was meant
to be a metaphor for “number of bits/bytes” being transported (“by the
semi”).  

> 

> That said, aren’t 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 that’s 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 that’s 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@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@auckland.ac.nz

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

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

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

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

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

>>> Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG
<ippm@ietf.org>; libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via
Starlink <starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>;
bloat <bloat@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 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@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@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

>>> _______________________________________________

>>> Starlink mailing list

>>> Starlink@lists.bufferbloat.net

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

>> 

>>  

>> -- 

>> Bruce Perens K6BP

>> 

>> 

>> 

>> _______________________________________________

>> Starlink mailing list

>> Starlink@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@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@lists.bufferbloat.net

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


[-- Attachment #2: Type: text/html, Size: 38418 bytes --]

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

[Sebastian Moeller]

Hi Christoph,



> On Jan 5, 2023, at 22:19, Christoph Paasch via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> I think, the cloudflare test uses a single TCP connection, while Ookla/Fast/… use multiple connections.

	Indeed, cloudflare's test seems to use a single preferably IPv6 connection, while Ookla and fast default to multiple parallel connections, but both can be configured for single flow tests (while cloudflare's so far seems to be fixed on single flow). IMHO both single and multi-flow tests are helpful (but should be clearly report the number of flows actually used).

Packet captures are certainly helpful, but for a quick check something like `iftop -i wan` on an OpenWrt router already helps confirming the "flow-ness" of a test on-line.

Regards
	Sebastian


> 
> That’s probably the difference for you.
> 
> 
> Christoph
> 
>> On Jan 4, 2023, at 2:21 PM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
>> 
>> I don't know how to debug this, but the cloudflare speed test really sucks on my home wired network, compared to others. And also I discovered to my chagrin that the DSLReports speedtest is now broken, at least in my Chrome browser.
>>  
>> The speeds measured by Cloudflare are essentially 1/2 of both Ookla and Fast.com.
>>  
>> Cloudflare in my test config gives ~500/10 Mb/sec, with a download latency of 14.6 msec, upload latency of 11.6.
>>  
>> Oookla and Fast give ~980/25 Mb/sec, with "latency" being about 11 or 12 msec.
>>  
>> This difference is observed over a tuned "cake" install on my Linux router, and the home network is 10 GigE to my workstation from the router, and the router talks to my DOCSIS cable modem on RCN at 1 GigE, with RCN's product offering being its "Gig" product.
>>  
>> Now, I hate using Ookla and getting bombarded with ads! I don't really trust fast.com, but it used to be OK.
>>  
>> The real disappointment was that the DSL Reports speed test, which I used to recommend is so broken. It claims it can't reach any of its 3 selected test sites, because I may have an "alien script" and suggests my DNS might be "slow" or my Chrome might have browser malware.
>>  
>> Now, maybe Chrome has browser malware on my machine. This is troubling to a serious degree to me, and I will be investigating.
>>  
>> However, Cloudflare seems to be somewhat flaky to a significant degree. (It also doesn't seem to push a fast network connection nearly hard enough to measure lag under load, it seems to me).
>>  
>>  
>>  
>> On Wednesday, January 4, 2023 2:20pm, starlink-request@lists.bufferbloat.net said:
>> 
>> > Send Starlink mailing list submissions to
>> > starlink@lists.bufferbloat.net
>> > 
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> > https://lists.bufferbloat.net/listinfo/starlink
>> > or, via email, send a message with subject or body 'help' to
>> > starlink-request@lists.bufferbloat.net
>> > 
>> > You can reach the person managing the list at
>> > starlink-owner@lists.bufferbloat.net
>> > 
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of Starlink digest..."
>> > 
>> > 
>> > Today's Topics:
>> > 
>> > 1. Re: [Rpm] the grinch meets cloudflare's christmas present
>> > (jf@jonathanfoulkes.com)
>> > 
>> > 
>> > ----------------------------------------------------------------------
>> > 
>> > Message: 1
>> > Date: Wed, 4 Jan 2023 14:20:15 -0500
>> > From: "jf@jonathanfoulkes.com" <jf@jonathanfoulkes.com>
>> > To: Dave Taht <dave.taht@gmail.com>
>> > Cc: bloat <bloat@lists.bufferbloat.net>, libreqos
>> > <libreqos@lists.bufferbloat.net>, Cake List
>> > <cake@lists.bufferbloat.net>, Dave Taht via Starlink
>> > <starlink@lists.bufferbloat.net>, Rpm <rpm@lists.bufferbloat.net>,
>> > IETF IPPM WG <ippm@ietf.org>
>> > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
>> > present
>> > Message-ID: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com>
>> > Content-Type: text/plain; charset="utf-8"
>> > 
>> > 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:
>> > 
>> > -------------- next part --------------
>> > A non-text attachment was scrubbed...
>> > Name: CFSpeedTest_Gig35_20230104.png
>> > Type: image/png
>> > Size: 379539 bytes
>> > Desc: not available
>> > URL:
>> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment.png>
>> > -------------- next part --------------
>> > 
>> > 
>> > And an Ookla test run just afterward:
>> > 
>> > -------------- next part --------------
>> > A non-text attachment was scrubbed...
>> > Name: Speedtest_net_Gig35_20230104.png
>> > Type: image/png
>> > Size: 40589 bytes
>> > Desc: not available
>> > URL:
>> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment-0001.png>
>> > -------------- next part --------------
>> > 
>> > 
>> > 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@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@lists.bufferbloat.net
>> > > https://lists.bufferbloat.net/listinfo/rpm
>> > 
>> > 
>> > ------------------------------
>> > 
>> > Subject: Digest Footer
>> > 
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink
>> > 
>> > 
>> > ------------------------------
>> > 
>> > End of Starlink Digest, Vol 22, Issue 10
>> > ****************************************
>> >
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[Dave Taht]

I am going to start heavily recommending more folk take packet captures.


On Thu, Jan 5, 2023 at 1:19 PM Christoph Paasch via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> I think, the cloudflare test uses a single TCP connection, while Ookla/Fast/… use multiple connections.
>
> That’s probably the difference for you.
>
>
> Christoph
>
> On Jan 4, 2023, at 2:21 PM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
>
> I don't know how to debug this, but the cloudflare speed test really sucks on my home wired network, compared to others. And also I discovered to my chagrin that the DSLReports speedtest is now broken, at least in my Chrome browser.
>
>
>
> The speeds measured by Cloudflare are essentially 1/2 of both Ookla and Fast.com.
>
>
>
> Cloudflare in my test config gives ~500/10 Mb/sec, with a download latency of 14.6 msec, upload latency of 11.6.
>
>
>
> Oookla and Fast give ~980/25 Mb/sec, with "latency" being about 11 or 12 msec.
>
>
>
> This difference is observed over a tuned "cake" install on my Linux router, and the home network is 10 GigE to my workstation from the router, and the router talks to my DOCSIS cable modem on RCN at 1 GigE, with RCN's product offering being its "Gig" product.
>
>
>
> Now, I hate using Ookla and getting bombarded with ads! I don't really trust fast.com, but it used to be OK.
>
>
>
> The real disappointment was that the DSL Reports speed test, which I used to recommend is so broken. It claims it can't reach any of its 3 selected test sites, because I may have an "alien script" and suggests my DNS might be "slow" or my Chrome might have browser malware.
>
>
>
> Now, maybe Chrome has browser malware on my machine. This is troubling to a serious degree to me, and I will be investigating.
>
>
>
> However, Cloudflare seems to be somewhat flaky to a significant degree. (It also doesn't seem to push a fast network connection nearly hard enough to measure lag under load, it seems to me).
>
>
>
>
>
>
>
> On Wednesday, January 4, 2023 2:20pm, starlink-request@lists.bufferbloat.net said:
>
> > Send Starlink mailing list submissions to
> > starlink@lists.bufferbloat.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.bufferbloat.net/listinfo/starlink
> > or, via email, send a message with subject or body 'help' to
> > starlink-request@lists.bufferbloat.net
> >
> > You can reach the person managing the list at
> > starlink-owner@lists.bufferbloat.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Starlink digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: [Rpm] the grinch meets cloudflare's christmas present
> > (jf@jonathanfoulkes.com)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 4 Jan 2023 14:20:15 -0500
> > From: "jf@jonathanfoulkes.com" <jf@jonathanfoulkes.com>
> > To: Dave Taht <dave.taht@gmail.com>
> > Cc: bloat <bloat@lists.bufferbloat.net>, libreqos
> > <libreqos@lists.bufferbloat.net>, Cake List
> > <cake@lists.bufferbloat.net>, Dave Taht via Starlink
> > <starlink@lists.bufferbloat.net>, Rpm <rpm@lists.bufferbloat.net>,
> > IETF IPPM WG <ippm@ietf.org>
> > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
> > present
> > Message-ID: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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:
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: CFSpeedTest_Gig35_20230104.png
> > Type: image/png
> > Size: 379539 bytes
> > Desc: not available
> > URL:
> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment.png>
> > -------------- next part --------------
> >
> >
> > And an Ookla test run just afterward:
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: Speedtest_net_Gig35_20230104.png
> > Type: image/png
> > Size: 40589 bytes
> > Desc: not available
> > URL:
> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment-0001.png>
> > -------------- next part --------------
> >
> >
> > 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@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@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/rpm
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> > ------------------------------
> >
> > End of Starlink Digest, Vol 22, Issue 10
> > ****************************************
> >
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



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

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

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 7306 bytes --]

I think, the cloudflare test uses a single TCP connection, while Ookla/Fast/… use multiple connections.

That’s probably the difference for you.


Christoph

> On Jan 4, 2023, at 2:21 PM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> I don't know how to debug this, but the cloudflare speed test really sucks on my home wired network, compared to others. And also I discovered to my chagrin that the DSLReports speedtest is now broken, at least in my Chrome browser.
>  
> The speeds measured by Cloudflare are essentially 1/2 of both Ookla and Fast.com.
>  
> Cloudflare in my test config gives ~500/10 Mb/sec, with a download latency of 14.6 msec, upload latency of 11.6.
>  
> Oookla and Fast give ~980/25 Mb/sec, with "latency" being about 11 or 12 msec.
>  
> This difference is observed over a tuned "cake" install on my Linux router, and the home network is 10 GigE to my workstation from the router, and the router talks to my DOCSIS cable modem on RCN at 1 GigE, with RCN's product offering being its "Gig" product.
>  
> Now, I hate using Ookla and getting bombarded with ads! I don't really trust fast.com, but it used to be OK.
>  
> The real disappointment was that the DSL Reports speed test, which I used to recommend is so broken. It claims it can't reach any of its 3 selected test sites, because I may have an "alien script" and suggests my DNS might be "slow" or my Chrome might have browser malware.
>  
> Now, maybe Chrome has browser malware on my machine. This is troubling to a serious degree to me, and I will be investigating.
>  
> However, Cloudflare seems to be somewhat flaky to a significant degree. (It also doesn't seem to push a fast network connection nearly hard enough to measure lag under load, it seems to me).
>  
>  
>  
> On Wednesday, January 4, 2023 2:20pm, starlink-request@lists.bufferbloat.net said:
> 
> > Send Starlink mailing list submissions to
> > starlink@lists.bufferbloat.net
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.bufferbloat.net/listinfo/starlink
> > or, via email, send a message with subject or body 'help' to
> > starlink-request@lists.bufferbloat.net
> > 
> > You can reach the person managing the list at
> > starlink-owner@lists.bufferbloat.net
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Starlink digest..."
> > 
> > 
> > Today's Topics:
> > 
> > 1. Re: [Rpm] the grinch meets cloudflare's christmas present
> > (jf@jonathanfoulkes.com)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Wed, 4 Jan 2023 14:20:15 -0500
> > From: "jf@jonathanfoulkes.com" <jf@jonathanfoulkes.com>
> > To: Dave Taht <dave.taht@gmail.com>
> > Cc: bloat <bloat@lists.bufferbloat.net>, libreqos
> > <libreqos@lists.bufferbloat.net>, Cake List
> > <cake@lists.bufferbloat.net>, Dave Taht via Starlink
> > <starlink@lists.bufferbloat.net>, Rpm <rpm@lists.bufferbloat.net>,
> > IETF IPPM WG <ippm@ietf.org>
> > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
> > present
> > Message-ID: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com>
> > Content-Type: text/plain; charset="utf-8"
> > 
> > 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:
> > 
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: CFSpeedTest_Gig35_20230104.png
> > Type: image/png
> > Size: 379539 bytes
> > Desc: not available
> > URL:
> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment.png>
> > -------------- next part --------------
> > 
> > 
> > And an Ookla test run just afterward:
> > 
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: Speedtest_net_Gig35_20230104.png
> > Type: image/png
> > Size: 40589 bytes
> > Desc: not available
> > URL:
> > <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment-0001.png>
> > -------------- next part --------------
> > 
> > 
> > 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@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@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/rpm
> > 
> > 
> > ------------------------------
> > 
> > Subject: Digest Footer
> > 
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> > 
> > 
> > ------------------------------
> > 
> > End of Starlink Digest, Vol 22, Issue 10
> > ****************************************
> >
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #2: Type: text/html, Size: 10618 bytes --]

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

[Sebastian Moeller]

Hi RR,


> On Jan 5, 2023, at 04:11, Dick Roy via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
>  
>  
> From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of Dave Collier-Brown via Starlink
> Sent: Wednesday, January 4, 2023 6:48 PM
> To: starlink@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] I’ve not heard of that usage before.  The units aren’t commensurate either. 
> 
> Using it for volume? Arguably more like fraudulent...
> 
> [RR] I don’t think that was Bob’s intent.  I think “load volume” was meant to be a metaphor for “number of bits/bytes” being transported (“by the semi”).  
> 
> That said, aren’t 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/Telekommunikation/Unternehmen_Institutionen/Anbieterpflichten/Kundenschutz/Transparenzmaß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).")

--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@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@auckland.ac.nz
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> **************************************************************** 
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
>>> Sent: Thursday, January 5, 2023 9:02 AM
>>> To: jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
>>> Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG <ippm@ietf.org>; libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>; bloat <bloat@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 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@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@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
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> 
>>  
>> -- 
>> Bruce Perens K6BP
>> 
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[rjmcmahon]

The thing that works for gamers are colors, e.g. green, yellow and red. 
Basically, if the game slows down to a bothersome experience the 
"latency indicator" goes from green to yellow. If the game slows down to 
be unplayable it goes to red and the "phone" mfg gets lots of 
complaints. Why we call a handheld computer a phone is a whole other 
discussion.

Bob
> 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@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@auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/ [1]
>> ****************************************************************
>> 
>> -------------------------
>> 
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
>> rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
>> Sent: Thursday, January 5, 2023 9:02 AM
>> To: jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
>> Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG
>> <ippm@ietf.org>; libreqos <libreqos@lists.bufferbloat.net>; Dave
>> Taht via Starlink <starlink@lists.bufferbloat.net>; Rpm
>> <rpm@lists.bufferbloat.net>; bloat <bloat@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 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@lists.bufferbloat.net> 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
>> [3]
>>>> Dave Täht CEO, TekLibre, LLC
>>>> 
>> 
> <image.png><tcp_nup-2023-01-04T090937.211620.LTE.flent.gz>_______________________________________________
>>>> Rpm mailing list
>>>> Rpm@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/rpm [4]
>>> 
>>> 
>>> _______________________________________________
>>> Rpm mailing list
>>> Rpm@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm [4]
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> --
> 
> Bruce Perens K6BP
> 
> Links:
> ------
> [1] http://www.cs.auckland.ac.nz/%7Eulrich/
> [2] https://speed.cloudflare.com
> [3] 
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> [4] https://lists.bufferbloat.net/listinfo/rpm

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

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 7240 bytes --]

 

 

  _____  

From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
Dave Collier-Brown via Starlink
Sent: Wednesday, January 4, 2023 6:48 PM
To: starlink@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] I’ve not heard of that usage before.  The units aren’t commensurate
either. 

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

[RR] I don’t think that was Bob’s intent.  I think “load volume” was meant
to be a metaphor for “number of bits/bytes” being transported (“by the
semi”).  

That said, aren’t 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.  

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@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@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
<http://www.cs.auckland.ac.nz/%7Eulrich/> 
**************************************************************** 


  _____  


From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
Sent: Thursday, January 5, 2023 9:02 AM
To: jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG <ippm@ietf.org>;
libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via Starlink
<starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>; bloat
<bloat@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 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@lists.bufferbloat.net> wrote:
>> 
>> Please try the new, the shiny, the really wonderful test here:
>> https://speed.cloudflare.com/ <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@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

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink




 

-- 

Bruce Perens K6BP






_______________________________________________
Starlink mailing list
Starlink@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@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.


[-- Attachment #2: Type: text/html, Size: 19394 bytes --]

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

[Dave Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 7002 bytes --]

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

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

--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@lists.bufferbloat.net<mailto:starlink@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@auckland.ac.nz<mailto:u.speidel@auckland.ac.nz>
http://www.cs.auckland.ac.nz/~ulrich/<http://www.cs.auckland.ac.nz/%7Eulrich/>
****************************************************************
________________________________
From: Starlink <starlink-bounces@lists.bufferbloat.net<mailto:starlink-bounces@lists.bufferbloat.net>> on behalf of rjmcmahon via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>
Sent: Thursday, January 5, 2023 9:02 AM
To: jf@jonathanfoulkes.com<mailto:jf@jonathanfoulkes.com> <jf@jonathanfoulkes.com<mailto:jf@jonathanfoulkes.com>>
Cc: Cake List <cake@lists.bufferbloat.net<mailto:cake@lists.bufferbloat.net>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>; libreqos <libreqos@lists.bufferbloat.net<mailto:libreqos@lists.bufferbloat.net>>; Dave Taht via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>>; Rpm <rpm@lists.bufferbloat.net<mailto:rpm@lists.bufferbloat.net>>; bloat <bloat@lists.bufferbloat.net<mailto:bloat@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 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@lists.bufferbloat.net<mailto:rpm@lists.bufferbloat.net>> wrote:
>>
>> Please try the new, the shiny, the really wonderful test here:
>> https://speed.cloudflare.com/<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@lists.bufferbloat.net<mailto:Rpm@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/rpm
>
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net<mailto:Rpm@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/rpm
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink


--
Bruce Perens K6BP



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net<mailto:Starlink@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@indexexchange.com<mailto:dave.collier-brown@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.

[-- Attachment #2: Type: text/html, Size: 12185 bytes --]

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

[Bruce Perens]

[-- Attachment #1: Type: text/plain, Size: 4941 bytes --]

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@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@auckland.ac.nz
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
> ------------------------------
> *From:* Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
> rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
> *Sent:* Thursday, January 5, 2023 9:02 AM
> *To:* jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
> *Cc:* Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG <ippm@ietf.org>;
> libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via Starlink <
> starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>; bloat <
> bloat@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 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@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@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
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Bruce Perens K6BP

[-- Attachment #2: Type: text/html, Size: 8553 bytes --]

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

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 6557 bytes --]


I don't know how to debug this, but the cloudflare speed test really sucks on my home wired network, compared to others. And also I discovered to my chagrin that the DSLReports speedtest is now broken, at least in my Chrome browser.
 
The speeds measured by Cloudflare are essentially 1/2 of both Ookla and Fast.com.
 
Cloudflare in my test config gives ~500/10 Mb/sec, with a download latency of 14.6 msec, upload latency of 11.6.
 
Oookla and Fast give ~980/25 Mb/sec, with "latency" being about 11 or 12 msec.
 
This difference is observed over a tuned "cake" install on my Linux router, and the home network is 10 GigE to my workstation from the router, and the router talks to my DOCSIS cable modem on RCN at 1 GigE, with RCN's product offering being its "Gig" product.
 
Now, I hate using Ookla and getting bombarded with ads! I don't really trust fast.com, but it used to be OK.
 
The real disappointment was that the DSL Reports speed test, which I used to recommend is so broken. It claims it can't reach any of its 3 selected test sites, because I may have an "alien script" and suggests my DNS might be "slow" or my Chrome might have browser malware.
 
Now, maybe Chrome has browser malware on my machine. This is troubling to a serious degree to me, and I will be investigating.
 
However, Cloudflare seems to be somewhat flaky to a significant degree. (It also doesn't seem to push a fast network connection nearly hard enough to measure lag under load, it seems to me).
 
 
 
On Wednesday, January 4, 2023 2:20pm, starlink-request@lists.bufferbloat.net said:



> Send Starlink mailing list submissions to
> starlink@lists.bufferbloat.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.bufferbloat.net/listinfo/starlink
> or, via email, send a message with subject or body 'help' to
> starlink-request@lists.bufferbloat.net
> 
> You can reach the person managing the list at
> starlink-owner@lists.bufferbloat.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Starlink digest..."
> 
> 
> Today's Topics:
> 
> 1. Re: [Rpm] the grinch meets cloudflare's christmas present
> (jf@jonathanfoulkes.com)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 4 Jan 2023 14:20:15 -0500
> From: "jf@jonathanfoulkes.com" <jf@jonathanfoulkes.com>
> To: Dave Taht <dave.taht@gmail.com>
> Cc: bloat <bloat@lists.bufferbloat.net>, libreqos
> <libreqos@lists.bufferbloat.net>, Cake List
> <cake@lists.bufferbloat.net>, Dave Taht via Starlink
> <starlink@lists.bufferbloat.net>, Rpm <rpm@lists.bufferbloat.net>,
> IETF IPPM WG <ippm@ietf.org>
> Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
> present
> Message-ID: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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:
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: CFSpeedTest_Gig35_20230104.png
> Type: image/png
> Size: 379539 bytes
> Desc: not available
> URL:
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment.png>
> -------------- next part --------------
> 
> 
> And an Ookla test run just afterward:
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Speedtest_net_Gig35_20230104.png
> Type: image/png
> Size: 40589 bytes
> Desc: not available
> URL:
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230104/d89867fe/attachment-0001.png>
> -------------- next part --------------
> 
> 
> 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@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@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> ------------------------------
> 
> End of Starlink Digest, Vol 22, Issue 10
> ****************************************
> 

[-- Attachment #2: Type: text/html, Size: 10005 bytes --]

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

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 4507 bytes --]

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<mailto:u.speidel@auckland.ac.nz>
http://www.cs.auckland.ac.nz/~ulrich/<http://www.cs.auckland.ac.nz/%7Eulrich/>
****************************************************************
________________________________
From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of rjmcmahon via Starlink <starlink@lists.bufferbloat.net>
Sent: Thursday, January 5, 2023 9:02 AM
To: jf@jonathanfoulkes.com <jf@jonathanfoulkes.com>
Cc: Cake List <cake@lists.bufferbloat.net>; IETF IPPM WG <ippm@ietf.org>; libreqos <libreqos@lists.bufferbloat.net>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; Rpm <rpm@lists.bufferbloat.net>; bloat <bloat@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 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@lists.bufferbloat.net> wrote:
>>
>> Please try the new, the shiny, the really wonderful test here:
>> https://speed.cloudflare.com/<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<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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/rpm<https://lists.bufferbloat.net/listinfo/rpm>
>
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm<https://lists.bufferbloat.net/listinfo/rpm>
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink<https://lists.bufferbloat.net/listinfo/starlink>

[-- Attachment #2: Type: text/html, Size: 6806 bytes --]

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

[rjmcmahon]

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 
>> <rpm@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/rpm
> 
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[jf]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

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:


[-- Attachment #2: CFSpeedTest_Gig35_20230104.png --]
[-- Type: image/png, Size: 379539 bytes --]

[-- Attachment #3: Type: text/plain, Size: 41 bytes --]



And an Ookla test run just afterward:


[-- Attachment #4: Speedtest_net_Gig35_20230104.png --]
[-- Type: image/png, Size: 40589 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1897 bytes --]



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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm