From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Wed, 5 Jun 2024 13:36:14 +0200 [thread overview]
Message-ID: <97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com> (raw)
In-Reply-To: <1078E544-F61B-4289-BCA1-BCDD9FA77481@ieee.org>
[-- Attachment #1: Type: text/plain, Size: 7988 bytes --]
Le 04/06/2024 à 22:58, Eugene Y Chang via Starlink a écrit :
> For automobiles, the sensation of speed comes from engine noise and
> the G-force at the seat-of-your-pants.
>
> I think of it as mostly the second derivative of the motion (aka
> acceleration).
>
> For snappiness of a network action, it is the time interval from
> activation to completion. This perception can be enhanced by giving
> quick feedback (response) while many things are still in motion (still
> incomplete).
>
> We do need to agree on what makes a network snappy and how that is
> measured.
I think a part of qualifying a communications network as 'snappy' is to
hold a 1-to-1 long-range audio conversation that acts as much as
possible as an in-person conversation to a person nearby. Landline
phones still excel at that and should be the benchmark.
A 'tele-presence' over satcom linking several persons each speaking in
high density bursts might need a 1ms RTT latency.
Alex
>
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> eugene.chang@ieee.org
>
>
>
>
>
>
>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> Good examples Stuart, it is quite interesting that as humanity we
>> have not come up with aggregate term what would fairly collapse the
>> dimensions to one single metric that would describe the snappy
>> feeling we intuitively seek for but can not quite verbalize. Vehicles
>> have the same issues, we have top speed (F1 at 360mph feels fast
>> compared to Starship at 16000mph), we have acceleration (Hot-rod
>> going 0 to 60 mph in 5 seconds feels high but pales in comparison to
>> Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor
>> plowing field with 300hp feels great but seems small compared to
>> 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of
>> torque wins a Tesla having 900Nm on wheel while at completely
>> different torque curve).
>>
>> Capacity has the same issue as literally the truck from your example
>> shipping magnetic tapes for "raw carry capacity" but it does not feel
>> responsive, snappy, good to handle in the "traffic" of Internet. We
>> have jitter, that could be compared to how a vehicle does in
>> repeatability of track laps? We have packet loss on how the car
>> handles on curves and does it slip off the track or on accelerations
>> spin the wheels? Download is speed forward, upload is almost like
>> speed at reverse gear usually far worse. Latency is like a lap track
>> as such, depends on the track, use-case specific tests "What time did
>> it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less
>> than 200ms?". Horse power feels much like raw capacity of the HW /
>> radio channel and techniques available beam forming, frequencies etc.
>> what was discussed here related to Starlink and even collectively
>> across different technologies. Speed is then instead of how much
>> specific combination of modem and base-station combo can achieve at
>> certain configuration? Torque feels like ability to maintain that
>> performance, closest we get is loaded performance in context of
>> bufferbloat?
>>
>> Watching videos on Netflix require different performance
>> characteristics than downloading a big update to Fortnite. One has
>> certain acceleration need to have snappy user experience but focus is
>> more on connection stability at certain bitrate. On the other hand
>> Fortnite update you want to be delivered at brute force speeds
>> without ruining others user experience.
>>
>> Maybe we can not find that aggregate property or metric, but just
>> need to be rigorous on making sure we accurately characterize each
>> dimension and standardize them so the confusion and play with words,
>> specially with marketing, get stabilized. Each needs to have
>> standardized benchmarks much like 3D rendering benchmarks and PC perf
>> tests are done? All that said, as I failed to come up with a perfect
>> term, "varying performance ISP links" feels like the right thing to
>> say? Now we have obfuscated to be able to throw any of the dimensions
>> underneath. Only thing left for us to do is then to provide those
>> dimensions like a nutrient labels. We are getting there? Nothing new
>> under the sun also to some extend.
>>
>> Just as a funny side note on the tractor marketing:
>>
>> ”Torque gives you the feeling of responsiveness and that the machine
>> does the right things,” Tapani Katila encapsulates his view. “The
>> torque is directly linked to the feeling of having power available in
>> the entire range of the power curve, resulting in more meaningful
>> work.” from
>> https://www.agcopower.com/power-is-important-but-torque-is-crucial/
>>
>> Seems like some other people are also trying to figure out what
>> dimensions to showcase to customers?
>>
>> Thank you for the thought provoking examples!
>>
>> Is bufferbloat property of a vehicle or characteristic of the road
>> design? Is it a question of ICE vs EV -or- roundabout vs crossing
>> with traffic lights? Feels more like a roundabout, no? Is this the
>> problem behind the objections?
>>
>> - Sauli
>>
>> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> On May 7, 2024, at 18:48, Dave Taht via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> > This was a wonderful post, rich!
>>
>> <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>
>>
>> I agree. Thanks for writing this Rich.
>>
>> One minor change I will request. Any time you write words like
>> “speed” or “fast”, pause and consider whether it would be more
>> accurate to use some other term like “capacity”, “bandwidth”, or
>> “throughput”. Part of what keeps us in this mess is that people
>> equate network capacity with “speed”, as if those terms were
>> synonyms. We can’t change how people think overnight, but at
>> least we can avoid further reinforcing that wrong thinking.
>>
>> If someone has 200 Mb/s Internet service and it feels slow, then
>> they might upgrade to 400 Mb/s Internet service and expect
>> everything to be uniformly twice as fast. We here know that
>> doubling the network capacity may make large downloads faster,
>> but everything else is most likely unchanged, and can be even worse.
>>
>> People never make this mistake in other contexts. If someone
>> commutes to work in their 20-foot RV feels that it’s too slow,
>> then upgrading to a 40-foot RV will not get them to work faster.
>> A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not
>> *faster*. If you are moving a vast amount of cargo that requires
>> multiple trips, then a larger truck will let you complete that
>> task in fewer trips. But for most daily driving, a bigger truck
>> will not get to your destination any quicker.
>>
>> Some simple edits:
>>
>> Instead of “varying speed ISP links” how about “varying capacity
>> ISP links”?
>>
>> Instead of “they profit if you decide your network is too slow
>> and you upgrade to a faster device/plan” how about “they profit
>> if you decide your network is too slow and you upgrade to a
>> higher throughput device/plan”?
>>
>> Stuart Cheshire
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
[-- Attachment #2: Type: text/html, Size: 18689 bytes --]
next prev parent reply other threads:[~2024-06-05 11:36 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s the Latency, FCC Colin_Higbie
2024-04-30 19:04 ` Eugene Y Chang
2024-05-01 0:36 ` David Lang
2024-05-01 1:30 ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01 1:52 ` Jim Forster
2024-05-01 3:59 ` Eugene Y Chang
2024-05-01 4:12 ` David Lang
2024-05-01 10:15 ` Frantisek Borsik
2024-05-01 18:51 ` Eugene Y Chang
2024-05-01 19:18 ` David Lang
2024-05-01 21:11 ` Frantisek Borsik
2024-05-01 22:10 ` Eugene Y Chang
2024-05-01 21:12 ` Eugene Y Chang
2024-05-01 21:27 ` Sebastian Moeller
2024-05-01 22:19 ` Eugene Y Chang
2024-05-06 11:25 ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11 ` Dave Collier-Brown
2024-05-07 0:43 ` Eugene Y Chang
2024-05-07 12:05 ` Dave Collier-Brown
[not found] ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47 ` Rich Brown
2024-05-07 0:38 ` Eugene Y Chang
2024-05-07 10:50 ` Rich Brown
2024-05-08 1:48 ` Dave Taht
2024-05-08 7:58 ` Frantisek Borsik
2024-05-08 8:01 ` Frantisek Borsik
2024-05-08 18:29 ` Eugene Y Chang
2024-06-04 18:19 ` Stuart Cheshire
2024-06-04 20:06 ` Sauli Kiviranta
2024-06-04 20:58 ` Eugene Y Chang
2024-06-05 11:36 ` Alexandre Petrescu [this message]
2024-06-05 13:08 ` Aidan Van Dyk
2024-06-05 13:28 ` Alexandre Petrescu
2024-06-05 13:40 ` Gert Doering
2024-06-05 13:43 ` Alexandre Petrescu
2024-06-05 14:16 ` David Lang
2024-06-05 15:10 ` Sebastian Moeller
2024-06-05 16:21 ` Alexandre Petrescu
2024-06-05 19:17 ` Eugene Y Chang
2024-06-04 23:03 ` Rich Brown
2024-06-04 23:36 ` [Starlink] Consumer Reportes (was: The "reasons" that bufferbloat isn't a problem) David Collier-Brown
2024-06-06 17:51 ` [Starlink] The "reasons" that bufferbloat isn't a problem Stuart Cheshire
2024-06-07 2:28 ` Dave Taht
2024-06-07 5:36 ` Sebastian Moeller
2024-06-07 7:51 ` Gert Doering
2024-05-02 19:17 ` [Starlink] Itʼs the Latency, FCC Michael Richardson
2024-05-02 9:09 ` [Starlink] It’s " Alexandre Petrescu
2024-05-02 9:28 ` Ulrich Speidel
2024-04-30 20:05 ` Sebastian Moeller
2024-05-02 9:21 ` Alexandre Petrescu
2024-05-07 12:13 [Starlink] The "reasons" that bufferbloat isn't a problem David Fernández
2024-05-07 12:46 ` Dave Collier-Brown
2024-05-07 19:09 ` Eugene Y Chang
2024-05-07 19:11 ` Dave Taht
2024-05-07 19:14 ` Jeremy Austin
2024-05-07 19:46 ` Dave Taht
2024-05-07 20:03 ` Eugene Y Chang
2024-05-07 20:05 ` Frantisek Borsik
2024-05-07 20:25 ` Eugene Y Chang
2024-05-08 9:31 David Fernández
2024-06-05 14:46 David Fernández
2024-06-05 14:57 ` Vint Cerf
2024-06-06 17:12 ` Michael Richardson
2024-06-06 10:18 ` Alexandre Petrescu
2024-06-06 10:37 ` Aidan Van Dyk
2024-06-06 10:33 ` Alexandre Petrescu
2024-06-05 15:16 David Fernández
2024-06-05 15:21 ` Bless, Roland (TM)
2024-06-05 15:32 ` David Fernández
2024-06-05 16:24 ` Sebastian Moeller
2024-06-06 23:10 ` Michael Richardson
2024-06-07 1:39 ` David Lang
2024-06-07 6:20 ` Sebastian Moeller
2024-06-07 17:41 ` Eugene Y Chang
2024-06-07 17:51 ` David Lang
2024-06-07 20:09 ` Eugene Y Chang
2024-06-08 1:53 ` David Lang
2024-06-05 16:23 ` Sebastian Moeller
2024-06-06 7:07 ` David Fernández
2024-06-06 7:41 ` Sebastian Moeller
2024-06-07 7:36 David Fernández
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com \
--to=alexandre.petrescu@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox