Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: David Lang <david@lang.hm>
Cc: Colin_Higbie <CHigbie1@Higbie.name>,
	 "starlink@lists.bufferbloat.net"
	<starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It?s the Latency, FCC
Date: Tue, 30 Apr 2024 17:40:20 -0700 (PDT)	[thread overview]
Message-ID: <4206ro7p-213r-so60-14s7-r23n39009p6p@ynat.uz> (raw)
In-Reply-To: <6ro9518q-478r-391s-r3s1-2291o7188nso@ynat.uz>

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

another note on video quality, how many people are watching '4k video' on a 6-8" 
mobile device?

higher resolution helps a lot for computer text and near static images, but is 
far less significant for watching videos.

Now, I watch a lot of space videos on a 42" monitor and I really notice the 
difference there between 4k and HD video, but that's not your typical studio 
produced video :-)

David Lang

On Tue, 30 Apr 2024, David Lang via Starlink wrote:

> As a note on video quality, look at what's in use in theaters. most are now 
> moving to 4k from 2k (just over HD)
>
> If theaters are still in the process of moving to 4k, I don't expect a lot of 
> content to be available at 8k+ for quite a few years.
>
> (even IMAX laser is only 4k, 70mm IMAX is roughly 18k, which has pretty 
> limited support)
>
> David Lang
>
> On Tue, 30 Apr 2024, Colin_Higbie via Starlink wrote:
>
>> Date: Tue, 30 Apr 2024 19:12:41 +0000
>> From: Colin_Higbie via Starlink <starlink@lists.bufferbloat.net>
>> Reply-To: Colin_Higbie <CHigbie1@Higbie.name>
>> To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> 
>>>>> Spotify lower quality than CD and still usable: one would check not 
>>>>> Spotify, but other services for audiophiles; some of these use 'DSD' 
>>>>> formats which go way beyond the so called high-def audio of 384khz 
>>>>> sampling freqs.  They dont 'stream' but download.  It is these 
>>>>> higher-than-384khz sampling rates equivalent (e.g. DSD1024 is the 
>>>>> equivalent of, I think of something like 10 times CD quality, I think). 
>>>>> If Spotify is the king of streamers, in the future other companies might 
>>>>> become the kings of something else than 'streaming', a name yet to be 
>>>>> invented.
>>>>> For each of them, it is true, normal use will not expose any more 
>>>>> advantage than the previous version (no advantage of 8K over 4K, no 
>>>>> advantage of 88KHz DVD audio over CD, etc) - yet the progress is ongoing 
>>>>> on and on, and nobody comes back to CD or to DVD audio or to SD 
>>>>> (standard definition video).
>>>>> Finally, 8K and DSD per se are requirements of just bandwidth.  The need 
>>>>> of latency should be exposed there, and that is not straightforward. 
>>>>> But higher bandwidths will come with lower latencies anyways.
>> 
>> Sorry, not sure if that's Alexandre or Sebastion, but to those points:
>> 
>> Spotify is absolutely the correct metric because it's the commercial leader 
>> (and roughly aligned from a quality perspective with Amazon Music, Apple, 
>> iHeart Radio, and the others popular services). The fact that it's lower 
>> quality than what audiophiles (myself included) would prefer only proves 
>> the point: most users (AKA the "market") don't care enough about the audio 
>> quality to want to go beyond CD quality. This is how the market establishes 
>> a "sufficient" level of quality. It's not a fixed figure and can change 
>> over time. If some musical artist creates some popular music that sounds 
>> meaningfully different to most listeners between 44.1kHz CD quality and the 
>> newer higher quality 96kHz 7.1 surround sound AND if the cost in equipment 
>> and connections to hear that difference were attainable to the mass market, 
>> then that could move the standard, but that's what it would take.
>> 
>> If it's only we few audiophiles who hear the difference, then the market 
>> won't care and will continue to say, "CD Quality is good enough. Now leave 
>> me alone with my music." :-)
>> 
>> If Spotify were in mono and sounded fuzzy like old AM radio, because that's 
>> clearly much worse even to the untrained ear, there would be an ongoing 
>> push for better quality audio. But that's not the situation.
>> 
>> Same logic with video. Is 12K better than 8K better than 4K? Yes. Is that a 
>> commercially important distinction? No, not in 2024, and the video quality 
>> change vectors would suggest it won't be in the next 10 years either (maybe 
>> will be after that). This is because at that quality level (like CD quality 
>> for audio), the digital quality achieves a level where either original 
>> recording equipment or the average human eye, brain, and ear can no longer 
>> distinguish between further advances. This is not an argument against 
>> over-provisioning bandwidth capacity to plan for the future, just laying 
>> out that a future with greater bandwidth needs per video stream is nothing 
>> that's coming soon.
>> 
>> (As a LAN aside and parallel to show there is a common precedent with 
>> networking equipment for these growth rates, home and small business 
>> routers have had a max bandwidth of 1Gbps at mass market pricing for over a 
>> decade. Arguably, that's still the upper limit today. 10Gbps is still 
>> extremely rare and expensive for routers with more than a single 10Gbps 
>> uplink port, with 2.5Gbps being the more common upgrade both on PC 
>> motherboards and in the router ports.)
>> 
>> SD -> HD is a HUGE improvement. SD is fuzzy (like mono AM radio). Facial 
>> expressions are hard to see without filling the screen with the person's 
>> face. HD -> 4K is noticeable, but much less significant. 4K with 
>> compression artifacts looks WORSE than a high quality 1080p stream. 4K -> 
>> 8K is literally imperceptible to typical people on typical sized TV's. 
>> While there are video cameras that can record at 8K in good lighting (even 
>> good reasonably priced studio digital cameras cannot record quality above 
>> 4K without excellent lighting), the picture quality limits are defined more 
>> by the optics and what's in focus than by the number of pixels. Further, 
>> for displaying an image even on an 83" TV, when viewed from more than a few 
>> feet away, must humans can't tell the difference between 4K and 8K even if 
>> the 8K image truly is sharper (and remember, they're usually not due to 
>> camera limitations).
>> 
>> But all of that technical explanation is also irrelevant. The fact is that 
>> Netflix, Amazon, Disney+, and some of the other big streaming services only 
>> offer 4K + HDR streams. None of them offer or have suggested that they 
>> intend to offer anything higher than that. The lion's share of TVs for sale 
>> today are also 4K TV. Even computer monitors, which have always been a 
>> leading indicator for TV resolutions, mostly top at 4K. There are a few 5K 
>> monitors, but the price jump from 4K to 5K is substantial. 8K monitors are 
>> rarer and even more expensive. This gives insight into a minimum timeframe 
>> before 4K is supplanted by 8K or something else: it's at least many years 
>> away. I suspect 3D may make a comeback before 8K (or maybe together – 
>> sometimes tech advances because it's paired with something else, like 
>> Blu-ray and 1080p).
>> 
>> I worry that many of the discussions here around bandwidth needs are 
>> academic and not market driven. Engineers and scientists know better than 
>> the market HOW to do something, HOW to solve the problems, but market 
>> always knows better than the engineers WHAT it wants. To be clear on a 
>> point dear to many here, the market may not know how to describe what it 
>> wants (e.g., the failing of ISPs to promote the importance of latency), but 
>> ignorance on technical matters is not the same as not knowing what it likes 
>> and wants. We can easily test for those distinctions via focus groups to 
>> let people actually experience the differences or via usage surveys to find 
>> out what users want to do. If you have a statistically significant sample, 
>> you will get a statistically significant response on what matters.
>> 
>> One last caveat: while the market is the ONLY group that matters in 
>> determining what it wants, the market also may be poor in explaining what 
>> it wants. If you'd asked the market what it wanted improved in a VCR, the 
>> market never would have said, "We want a DVD player" or "We want streaming 
>> video over the Internet." They would just say they don't like picture 
>> quality, rewinding tapes, tape wear, etc. All problems solved by DVD and 
>> modern streaming. So it's important for marketing teams working with 
>> engineers to ask the right questions and truly understand the responses so 
>> that clever engineers can innovate the best solutions to solve the market's 
>> pain points.
>> 
>> Hope that helps everyone here.
>> 
>> Cheers,
>> Colin
>> 
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of 
>> starlink-request@lists.bufferbloat.net
>> Sent: Tuesday, April 30, 2024 10:56 AM
>> To: starlink@lists.bufferbloat.net
>> Subject: Starlink Digest, Vol 37, Issue 12
>> 
>> 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: It’s the Latency, FCC (Sebastian Moeller)
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 30 Apr 2024 16:45:07 +0200
>> From: Sebastian Moeller <moeller0@gmx.de>
>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>> Cc: Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <A53E11CF-FDA1-4AAE-A6EC-51EDD3B85995@gmx.de>
>> Content-Type: text/plain;	charset=utf-8
>> 
>> Hi Alexandre,
>> 
>> 
>>> On 30. Apr 2024, at 16:40, Alexandre Petrescu 
>>> <alexandre.petrescu@gmail.com> wrote:
>>> 
>>> 
>>> Le 30/04/2024 à 16:32, Sebastian Moeller a écrit :
>>>> Hi Alexandre,
>>>> 
>>>> 
>>>> 
>>>>> On 30. Apr 2024, at 16:25, Alexandre Petrescu via Starlink 
>>>>> <starlink@lists.bufferbloat.net> wrote:
>>>>> 
>>>>> Colin,
>>>>> 8K usefulness over 4K: the higher the resolution the more it will be 
>>>>> possible to zoom in into paused images.  It is one of the advantages. 
>>>>> People dont do that a lot these days but why not in the future.
>>>> [SM] Because that is how in the past we envisioned the future, see here 
>>>> h++ps://www.youtube.com/watch?v=hHwjceFcF2Q 'enhance'...
>>>> 
>>>>> Spotify lower quality than CD and still usable: one would check not 
>>>>> Spotify, but other services for audiophiles; some of these use 'DSD' 
>>>>> formats which go way beyond the so called high-def audio of 384khz 
>>>>> sampling freqs.  They dont 'stream' but download.  It is these 
>>>>> higher-than-384khz sampling rates equivalent (e.g. DSD1024 is the 
>>>>> equivalent of, I think of something like 10 times CD quality, I think). 
>>>>> If Spotify is the king of streamers, in the future other companies might 
>>>>> become the kings of something else than 'streaming', a name yet to be 
>>>>> invented.
>>>>> For each of them, it is true, normal use will not expose any more 
>>>>> advantage than the previous version (no advantage of 8K over 4K, no 
>>>>> advantage of 88KHz DVD audio over CD, etc) - yet the progress is ongoing 
>>>>> on and on, and nobody comes back to CD or to DVD audio or to SD 
>>>>> (standard definition video).
>>>>> Finally, 8K and DSD per se are requirements of just bandwidth.  The need 
>>>>> of latency should be exposed there, and that is not straightforward. 
>>>>> But higher bandwidths will come with lower latencies anyways.
>>>> [SM] How that? Capacity and latency are largely independent... think a 
>>>> semi truck full of harddisks from NYC to LA has decent 
>>>> capacity/'bandwidth' but lousy latency...
>>> 
>>> I agree with you: two distinct parameters, bandwidth and latency.  But 
>>> they evolve simultenously, relatively bound by a constant relationship. 
>>> For any particular link  technology (satcom is one) the bandwidth and 
>>> latency are in a constant relationship.  One grows, the other diminishes. 
>>> There are exceptions too, in some details.
>>> 
>>> (as for the truck full of harddisks, and jumbo jets full of DVDs - they 
>>> are just concepts: striking good examples of how enormous bandwidths are 
>>> possible, but still to see in practice; physicsts also talked about a 
>>> train transported by a train transported by a train and so on, to overcome 
>>> the speed of light: another striking example, but not in practice).
>> 
>> [SM] Not any more, but Amazon did offer a a storage truck (for latency 
>> insensitive transfers of huge data)
>> h++ps://www.cnbc.com/2024/04/17/aws-stops-selling-snowmobile-truck-for-c
>> h++loud-migrations.html
>> so this is more than just a concept...
>> 
>>> 
>>> Alex
>>> 
>>>> 
>>>> 
>>>>> The quest of latency requirements might be, in fact, a quest to see how 
>>>>> one could use that low latency technology that is possible and available 
>>>>> anyways.
>>>>> Alex
>>>>> Le 30/04/2024 à 16:00, Colin_Higbie via Starlink a écrit :
>>>>>> David Fernández, those bitrates are safe numbers, but many streams 
>>>>>> could get by with less at those resolutions. H.265 compression is at a 
>>>>>> variable bit rate with simpler scenes requiring less bandwidth. Note 
>>>>>> that 4K with HDR (30 bits per pixel rather than 24) consistently also 
>>>>>> fits within 25Mbps.
>>>>>> 
>>>>>> David Lang, HDR is a requirement for 4K programming. That is not to say 
>>>>>> that all 4K streams are in HDR, but in setting a required bandwidth, 
>>>>>> because 4K signals can include HDR, the required bandwidth must 
>>>>>> accommodate and allow for HDR. That said, I believe all modern 4K 
>>>>>> programming on Netflix and Amazon Prime is HDR. Note David Fernández' 
>>>>>> point that Spain independently reached the same conclusion as the US 
>>>>>> streaming services of 25Mbps requirement for 4K.
>>>>>> 
>>>>>> Visually, to a person watching and assuming an OLED (or microLED) 
>>>>>> display capable of showing the full color and contrast gamut of HDR 
>>>>>> (LCD can't really do it justice, even with miniLED backlighting), the 
>>>>>> move to HDR from SDR is more meaningful in most situations than the 
>>>>>> move from 1080p to 4K. I don't believe going to further resolutions, 
>>>>>> scenes beyond 4K (e.g., 8K), will add anything meaningful to a movie or 
>>>>>> television viewer over 4K. Video games could benefit from the added 
>>>>>> resolution, but lens aberration in cameras along with focal length and 
>>>>>> limited depth of field render blurriness of even a sharp picture 
>>>>>> greater than the pixel size in most scenes beyond about 4K - 5.5K. 
>>>>>> Video games don’t suffer this problem because those scenes are 
>>>>>> rendered, eliminating problems from camera lenses. So video games may 
>>>>>> still benefit from 8K resolution, but streaming programming won’t.
>>>>>> 
>>>>>> There is precedent for this in the audio streaming world: audio 
>>>>>> streaming bitrates have retracted from prior peaks. Even though 48kHz 
>>>>>> and higher bitrate audio available on DVD is superior to the audio 
>>>>>> quality of 44.1kHz CDs, Spotify and Apple and most other streaming 
>>>>>> services stream music at LOWER quality than CD. It’s good enough for 
>>>>>> most people to not notice the difference. I don’t see much push in the 
>>>>>> foreseeable future for programming beyond UHD (4K + HDR). That’s not to 
>>>>>> say never, but there’s no real benefit to it with current camera tech 
>>>>>> and screen sizes.
>>>>>> 
>>>>>> Conclusion: for video streaming needs over the next decade or so, 
>>>>>> 25Mbps should be appropriate. As David Fernández rightly points out, 
>>>>>> H.266 and other future protocols will improve compression capabilities 
>>>>>> and reduce bandwidth needs at any given resolution and color bit depth, 
>>>>>> adding a bit more headroom for small improvements.
>>>>>> 
>>>>>> Cheers,
>>>>>> Colin
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf
>>>>>> Of starlink-request@lists.bufferbloat.net
>>>>>> Sent: Tuesday, April 30, 2024 9:31 AM
>>>>>> To: starlink@lists.bufferbloat.net
>>>>>> Subject: Starlink Digest, Vol 37, Issue 9
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Message: 2
>>>>>> Date: Tue, 30 Apr 2024 11:54:20 +0200
>>>>>> From: David Fernández <davidfdzp@gmail.com>
>>>>>> To: starlink <starlink@lists.bufferbloat.net>
>>>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>>>> Message-ID:
>>>>>> <CAC=tZ0rrmWJUNLvGupw6K8ogADcYLq-eyW7Bjb209oNDWGfVSA@mail.gmail.com
>>>>>>> 
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>> 
>>>>>> Last February, TV broadcasting in Spain left behind SD definitively and 
>>>>>> moved to HD as standard quality, also starting to regularly broadcast a 
>>>>>> channel with 4K quality.
>>>>>> 
>>>>>> A 4K video (2160p) at 30 frames per second, handled with the HEVC 
>>>>>> compression codec (H.265), and using 24 bits per pixel, requires 25 
>>>>>> Mbit/s.
>>>>>> 
>>>>>> Full HD video (1080p) requires 10 Mbit/s.
>>>>>> 
>>>>>> For lots of 4K video encoded at < 20 Mbit/s, it may be hard to 
>>>>>> distinguish it visually from the HD version of the same video (this was 
>>>>>> also confirmed by SBTVD Forum Tests).
>>>>>> 
>>>>>> Then, 8K will come, eventually, requiring a minimum of ~32 Mbit/s:
>>>>>> https://dvb.org/news/new-generation-of-terrestrial-services-taking-
>>>>>> shape-in-europe
>>>>>> 
>>>>>> The latest codec VVC (H.266) may reduce the required data rates by at 
>>>>>> least 27%, at the expense of more computing power required, but somehow 
>>>>>> it is claimed it will be more energy efficient.
>>>>>> https://dvb.org/news/dvb-prepares-the-way-for-advanced-4k-and-8k-br
>>>>>> oadcast-and-broadband-television
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> David
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

  reply	other threads:[~2024-05-01  0:40 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2775.1714488970.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:12 ` [Starlink] It’s " Colin_Higbie
2024-04-30 19:31   ` Eugene Y Chang
2024-05-01  0:33     ` David Lang
2024-05-01  0:31   ` David Lang
2024-05-01  0:40     ` David Lang [this message]
2024-05-06 15:42 David Fernández
  -- strict thread matches above, loose matches on Subject: below --
2024-05-06 13:21 David Fernández
2024-05-03  9:09 [Starlink] It's " David Fernández
     [not found] <mailman.2877.1714641707.1074.starlink@lists.bufferbloat.net>
2024-05-02 14:47 ` [Starlink] It’s " Colin_Higbie
2024-05-02 19:50   ` Frantisek Borsik
2024-05-06 11:19     ` Alexandre Petrescu
2024-05-06 13:43       ` Nathan Owens
2024-05-06 15:22         ` Colin_Higbie
2024-05-14 19:23       ` Colin_Higbie
2024-05-15  6:52         ` Sebastian Moeller
2024-05-15 14:55           ` Colin_Higbie
2024-05-03  1:48   ` Ulrich Speidel
2024-05-03  7:22     ` Jeremy Austin
2024-05-03  9:02     ` Alexandre Petrescu
2024-05-03  8:29   ` Alexandre Petrescu
2024-05-03  8:34   ` Alexandre Petrescu
2024-05-01 16:35 [Starlink] It's " David Fernández
2024-05-01  8:41 David Fernández
     [not found] <mailman.2785.1714507537.1074.starlink@lists.bufferbloat.net>
2024-04-30 20:48 ` [Starlink] It’s " Colin  Higbie
2024-04-30 20:49   ` Colin_Higbie
2024-05-01  0:51   ` David Lang
     [not found] <mailman.2779.1714503924.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:31 ` Colin_Higbie
2024-04-30 19:51   ` Eugene Y Chang
2024-04-30 21:07     ` Dave Taht
2024-04-30 21:22       ` Frantisek Borsik
2024-04-30 22:02         ` Dave Taht
2024-04-30 22:03           ` Dave Taht
2024-04-30 22:05         ` [Starlink] Fwd: " Rich Brown
2024-04-30 22:10           ` Dave Taht
2024-04-30 22:42             ` [Starlink] " Rich Brown
2024-04-30 23:06               ` Dave Taht
2024-04-30 22:31           ` Eugene Y Chang
2024-04-30 21:22       ` Eugene Y Chang
2024-04-30 21:35         ` Frantisek Borsik
2024-04-30 21:53           ` Eugene Y Chang
2024-05-01  0:54             ` David Lang
2024-05-01  7:27             ` Frantisek Borsik
2024-05-01 19:26               ` Eugene Y Chang
2024-05-14 16:05                 ` Dave Taht
     [not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` Colin_Higbie
2024-04-30 19:04   ` Eugene Y Chang
2024-05-01  0:36     ` David Lang
2024-05-02  9:09     ` Alexandre Petrescu
2024-05-02  9:28       ` Ulrich Speidel
2024-04-30 20:05   ` Sebastian Moeller
2024-05-02  9:21     ` Alexandre Petrescu
     [not found] <mailman.2769.1714483871.1074.starlink@lists.bufferbloat.net>
2024-04-30 14:00 ` Colin_Higbie
2024-04-30 14:25   ` Alexandre Petrescu
2024-04-30 14:32     ` Sebastian Moeller
2024-04-30 14:40       ` Alexandre Petrescu
2024-04-30 14:45         ` Sebastian Moeller
2024-04-30 14:56           ` Alexandre Petrescu
2024-04-30 15:04             ` David Lang
2024-04-30 15:01         ` David Lang
2024-04-30  9:54 David Fernández
     [not found] <mailman.2495.1710610618.1074.starlink@lists.bufferbloat.net>
2024-03-16 19:10 ` Colin_Higbie
2024-03-16 19:32   ` Sebastian Moeller
2024-03-17 17:00   ` Alexandre Petrescu
2024-03-17 19:26     ` Frantisek Borsik
     [not found] <mailman.11.1710518402.17089.starlink@lists.bufferbloat.net>
2024-03-15 18:32 ` Colin  Higbie
2024-03-15 18:41   ` Colin_Higbie
2024-03-15 19:53     ` Spencer Sevilla
2024-03-15 20:31       ` Colin_Higbie
2024-03-16 17:18         ` Alexandre Petrescu
2024-03-16 17:21           ` Alexandre Petrescu
2024-03-16 17:36           ` Sebastian Moeller
2024-03-16 22:51             ` David Lang
2024-03-15 23:07       ` David Lang
2024-03-16 18:45         ` [Starlink] Itʼs " Colin_Higbie
2024-03-16 23:05           ` David Lang
2024-03-17 15:47             ` [Starlink] It’s " Colin_Higbie
2024-03-16 18:51         ` [Starlink] It?s " Gert Doering
2024-03-16 23:08           ` David Lang
2024-04-30  0:39   ` [Starlink] It’s " David Lang
2024-03-15  3:53 Larry Press
2024-03-15  5:33 ` Dave Taht
2024-03-15 21:14   ` Michael Richardson

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=4206ro7p-213r-so60-14s7-r23n39009p6p@ynat.uz \
    --to=david@lang.hm \
    --cc=CHigbie1@Higbie.name \
    --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