Well, from an iperf 2 perspective channel capacity of a TCP socket is
information/time. I think that's also more or less how Shannon defined
it. I don't think channel capacity matters if it's measured or somehow
otherwise computed, or maybe never even known. It exists on its own
merits regardless ;)
"Shannon's Theorem gives an upper bound to the capacity of a link, in
bits per second (bps), as a function of the available bandwidth and the
signal-to-noise ratio of the link."
"the channel capacity of a given channel is the highest information rate
(in units of information per unit time) that can be achieved with
arbitrarily small error probability."
https://en.wikipedia.org/wiki/Channel_capacity
Then, there is latency which is delay in units time. So why do we use
the term "speed" when we're talking about delay? I find it similar to
the speed of causality except applied to us mere mortal computer
programmers. Our programs block while waiting on those delays. Network
engineers reducing those delays in turn can increase the speed of the
programmer's objectives. So speed here really is the speed of a coupled
distributed computer system. Never to exceed the speed of light but we
should try to get there anyway.
Bob
OK, so now we are all showing our age! And yes, the lexicon has
become really muddied … generally the result of someone who doesn't
know (and thinking they do J), speaking the loudest and the longest
and whaddaya know, all of a sudden we have "speed tests" and "capacity
tests", when really what is happening is that
"data/information/communication rate" is being "measured/estimated".
Neither "speed" nor "capacity" is being "tested". Oh, for the good ole
days when … J
-------------------------
From: Starlink [mailto:[email protected]] On
Behalf Of Ulrich Speidel via Starlink
Sent: Wednesday, January 4, 2023 1:17 PM
To: [email protected]; rjmcmahon
Cc: Dave Taht via Starlink; bloat
Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas
present
The use of the term "speed" in communications used to be restricted to
the speed of light (or whatever propagation speed one happened to be
dealing with. Everything else was a "rate". Maybe I'm old-fashioned
but I think talking about "speed tests" muddies the waters rather a
lot.
--
****************************************************************
Dr. Ulrich Speidel
Department of Computer Science
Room 303S.594
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
[email protected]
http://www.cs.auckland.ac.nz/~ulrich/ [1]
****************************************************************
-------------------------
From: Starlink <[email protected]> on behalf of
rjmcmahon via Starlink <[email protected]>
Sent: Thursday, January 5, 2023 9:02 AM
To: [email protected] <[email protected]>
Cc: Cake List <[email protected]>; IETF IPPM WG
<[email protected]>; libreqos <[email protected]>; Dave Taht
via Starlink <[email protected]>; Rpm
<[email protected]>; bloat <[email protected]>
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
<[email protected]> wrote:
Please try the new, the shiny, the really wonderful test here:
https://speed.cloudflare.com/ [2]
I would really appreciate some independent verification of
measurements using this tool. In my brief experiments it appears -
as
all the commercial tools to date - to dramatically understate the
bufferbloat, on my LTE, (and my starlink terminal is out being
hacked^H^H^H^H^H^Hworked on, so I can't measure that)
My test of their test reports 223ms 5G latency under load , where
flent reports over 2seconds. See comparison attached.
My guess is that this otherwise lovely new tool, like too many,
doesn't run for long enough. Admittedly, most web objects (their
target market) are small, and so long as they remain small and not
heavily pipelined this test is a very good start... but I'm pretty
sure cloudflare is used for bigger uploads and downloads than that.
There's no way to change the test to run longer either.
I'd love to get some results from other networks (compared as usual
to
flent), especially ones with cake on it. I'd love to know if they
measured more minimum rtts that can be obtained with fq_codel or
cake,
correctly.
Love Always,
The Grinch
--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
<image.png><tcp_nup-2023-01-04T090937.211620.LTE.flent.gz>_______________________________________________
Rpm mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/rpm
_______________________________________________
Rpm mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/rpm
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
Links:
------
[1] http://www.cs.auckland.ac.nz/%7Eulrich/
[2] https://speed.cloudflare.com
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
