Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
* Re: [Starlink] It’s the Latency, FCC
@ 2024-05-06 15:42 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-05-06 15:42 UTC (permalink / raw)
  To: starlink

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

" there is not a widely accepted standard for evaluating video quality (at
least not one of which I’m aware"

What about ITU-T BT.500? https://www.itu.int/rec/R-REC-BT.500
Well, AFAIK, Netflix invented VMAF because ITU methods are very expensive
to implement, not automated and PSNR was not good enough.

"I have no doubt that there exist today and will exist even more so in the
future superior compression that could lower the bitrate needed"
Yes, 25 Mbit/s is for HEVC (H.265), but the successor H.266 (VVC) is
already here and it reduces the data rate required by ~20%, but it seems
that Netflix may prefer AV1, which is between HEVC and VVC in terms of
performance.

Regards,

David F.

Date: Mon, 6 May 2024 15:22:04 +0000
From: Colin_Higbie <CHigbie1@Higbie.name>
To: Nathan Owens <nathan@nathan.io>, Alexandre Petrescu
        <alexandre.petrescu@gmail.com>
Cc: Frantisek Borsik <frantisek.borsik@gmail.com>,
        "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It’s the Latency, FCC
Message-ID:
        <
MN2PR16MB3391A263E084AE9B74C2DE5FF11C2@MN2PR16MB3391.namprd16.prod.outlook.com
>

Content-Type: text/plain; charset="utf-8"

Nathan,

While you hit the point in your second paragraph, namely that Apple
REQUIRES 25Mbps (as do others of the major streaming services, including
Netflix today), your first paragraph misses it. It doesn’t matter what is
POSSIBLE (unless you have the ability to persuade all streaming services to
implement those technologies and ensure they work for the lion’s share of
installed end-user equipment and 4K HDR streams, in which case, well done
and I would agree that a lower bitrate is sufficient). The ONLY factor that
matters in terms of required bandwidth to be considered a fully capable ISP
service is what the market demands for the mainstream Internet services.
That is 25Mbps.

As the article you linked to points out, those lower bitrates are NOT for
4K HDR (10-bit color depth per pixel). For those, even in the authors’
chosen examples, and possibly only at 8-bit color (not clear), the article
claims to only get down to a low of about 17Mbps for the highest quality.
I’ve seen other reports that say anything below 20Mbps will occasionally
fail on particular complex scenes that don’t compress well. Add a little
bit of overhead or assume some additional traffic (an important
consideration, given the raison d’être of this group – reduce latency under
load from multiple streams), and you’re back to 25Mbps on needed bandwidth
to support multiple concurrent activities.

While I concede there is not a widely accepted standard for evaluating
video quality (at least not one of which I’m aware), I dislike that Y axis
(Quality) on their graphs has no metric, especially without a definition
for how they define quality – is it based on lost data, % of pixels
expressing compression artifacts, pixel color drift, or something else they
created for the purpose of making their case? I would say that NONE of the
photos shown constitute a good or excellent quality level, where all show
significant compression artifacts at the high-contrast boundaries. These
are distinct from natural focal problems with analog systems that are not
contrast-dependent. Further, these all appear to be relatively static
scenes with just a few small moving objects – the kinds of frames and
scenes that compress extremely well. Again, this is why we must look to the
market to determine what it needs, not individual proposals.

The article also acknowledges that the graph points represent the average,
meaning some frames are better and some are worse. This is bad because with
any lossy compression system, there is a (subjective) “good enough” level,
where values above that don’t add much, but frames that are worse will
stand out as bad. You can’t just watch the average – you’re forced to also
watch the bad frames. In real-world usage, these will be the frames during
high-speed image changes – explosions in action movies or a fast-panning
scene), often the times when preserving fidelity are most important (e.g.,
you lose track of the football during the fast pan downfield, or you really
want to see the detail in the X-wing fighters as the dogfight leads to
explosions around them).

Further, that article is really targeting mobile usage for cellular
bandwidth, where many of these viewing issues are fundamentally different
from the 65” living room TV. The mobile display may offer 120Hz, but
showing a movie or show at 30Hz (except for some sports) is still the
standard.

Now, to be fair, I have no doubt that there exist today and will exist even
more so in the future superior compression that could lower the bitrate
needed at any given resolution and quality level. The one described in the
article could be an important step in that direction. No doubt Netflix
already has multiple economic incentives to reduce required bandwidth –
their own bandwidth costs, which are a substantial % of their total
operating costs, access to customers who can’t get 25Mbps connections,
competition from other streaming services if they can claim that their
streams are less affected by what others in the house are doing or are
higher quality at any given bandwidth, etc. As noted above, however, that
is all moot unless all of the major streamers adopt comparable bandwidth
reduction technologies and ALSO that all major existing home equipment can
support it today (i.e., without requiring people replace their TV’s or
STB’s). Absent that, it’s just a technical novelty that may or may not take
hold, like Betamax videotapes or HD-DVD.

On the contrary, what we see today is that the major streaming services
REQUIRE users to have 25Mbps connections in order to offer the 4K HDR
streams. Yes, users can lie and may find they can watch most of the 4K
content they wish with only 20Mbps or in some cases 15Mbps connections, but
that’s clearly not a reason why an ISP should say, “We don’t need to offer
25Mbps for our customers to be able to access any major streaming service.”

Cheers,
Colin

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

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [Starlink] It’s the Latency, FCC
@ 2024-05-06 13:21 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-05-06 13:21 UTC (permalink / raw)
  To: starlink, alexandre.petrescu

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

For " I dont know what MPEG codec is it, at what mbit/s speed" you may
check this:
https://lists.bufferbloat.net/pipermail/starlink/2024-April/002706.html

From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: Frantisek Borsik <frantisek.borsik@gmail.com>, Colin_Higbie
        <CHigbie1@higbie.name>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It’s the Latency, FCC
Message-ID: <298126c9-7854-47c5-a965-c0f89a855939@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"


Le 02/05/2024 à 21:50, Frantisek Borsik a écrit :
> Thanks, Colin. This was just another great read on video (and audio -
> in the past emails from you) bullet-proofing for the near future.
>
> To be honest, the consensus on the bandwidth overall in the
> bufferbloat related circles was in the 25/3 - 100/20 ballpark


To continue on this discussion of 25mbit/s (mbyte/s ?) of 4k, and 8k,
here are some more thoughts:

- about 25mbit/s bw needs for 4K:  hdmi cables for 4K HDR10 (high
dynamic range) are specified at 18gbit/s and not 25mbit/s (mbyte?).
These HDMI cables dont run IP.  But, supposedly, the displayed 4K image
is of a higher quality if played over hdmi (presumably from a player)
than from a server  remote on the Internet.   To achieve parity, maybe
one wants to run that hdmi flow from the server with IP, and at that
point the bandwidth requirement is higher than 25mbit/s.  This goes hand
in hand with the disc evolutions (triple-layer bluray discs of 120Gbyte
capacity is the most recent; I dont see signs of that to slow).

- in some regions, the terrestrial DVB (TV on radio frequencies, with
antenna receivers, not  IP) run at 4K HDR10 starting this year.  I dont
know what MPEG codec is it, at what mbit/s speed. But it is not over the
Internet.  This means that probably  ISPs are inclined to do more than
that 4K over the Internet, maybe 8K, to distinguish their service from
DVB.  The audience of these DVB streams is very wide, with cheap
one-time buy receivers (no subscription, like with ISP) already widely
available in electronics stores.

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

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [Starlink] It's the Latency, FCC
@ 2024-05-03  9:09 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-05-03  9:09 UTC (permalink / raw)
  To: starlink

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

Recent video codecs are very efficient denoisers, removing film grain from
old movies, so they don't look like the originals when decoded (and
disappointing some people).

There are ideas for solving this going on, like characterizing the film
grain with a model with some parameters. Then, the model and its
parameters, not the actual pixels with the noise, are transmitted and
generated at the decoder. with a processing that will make them ressemble
the originals (without being exactly the originals).

That is somehow a kind of semantic communication, in which instead of the
actual information, you transmit the meaningful information, not the pixels
at bit resolution. I see it a bit like using vector graphics instead of
pixels for images (SVG vs. PNG), to be able to generate images of arbitrary
resolution from the meaningful info. This is a way of breaking Shanon
capacity limits.

----------------------------------------------------------------------
Date: Fri, 3 May 2024 13:48:37 +1200
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] It’s the Latency, FCC
Message-ID: <77d8f31e-860b-478e-8f93-30cb6e0730ac@auckland.ac.nz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

There's also the not-so-minor issue of video compression, which
generally has the effect of removing largely imperceptible detail from
your video frames so your high-res video will fit through the pipeline
you've got to squeeze it through.

But this is a bit of a snag in its own right, as I found out about two
decades ago when I was still amazed at the fact that you could use the
parsing algorithms underpinning universal data compression to get an
estimate of how much information a digital object (say, a CCD image
frame) contained. So I set about with two Japanese colleagues to look at
the reference image sequences that pretty much everyone used to
benchmark their video compressors against. One of the surprising finds
was that the odd-numbered frames in the sequences had a distinctly
different amount of information in them than the even-numbered ones, yet
you couldn't tell from looking at the frames.

We more or less came to the conclusion that the camera that had been
used to record the world's most commonly used reference video sequences
had added a small amount of random noise to every second image. - the
effect (and estimated information content) dropped noticeably when we
progressively dropped the least significant bits in the pixels. We
published this:

KAWAHARADA, K., OHZEKI, K., SPEIDEL, U. 'Information and Entropy
Measurements on Video Sequences', 5th International Conference on
Information, Communications and Signal Processing (ICICS2005), Bangkok,
6-9 December 2005, p.1150-1154, DOI 10.1109/ICICS.2005.1689234

Did the world take notice? Of course not. But it still amuses me no end
that some people spent entire careers trying to optimise the compression
of these image sequences - and all that because of an obscure hardware
flaw that the cameras which their algorithms ended up on may not have
even suffered from.

Which brings me back to the question of how important bandwidth is. The
answer is: probably more important in the future. We're currently
relying mostly on CDNs for video delivery, but I can't fail but notice
the progress that's being made by AI-based video generation. Four or
five years ago, Gen-AI could barely compose a credible image. A couple
of years ago, it could do video sequences of a few seconds. Now we're up
to videos in the minutes.

If that development is sustained, you'll be able to tell your personal
electronic assistant / spy to dream up a personalised movie, say an
operatic sci-fi Western with car chases on the Titanic floating in
space, and it'll have it generated in no time starring the actors you
like. ETA: Around 2030 maybe?

But these things will be (a) data-heavy and (b) aren't well suited for
CDN delivery because you may be the only one to every see a particular
movie, so you'll either need to move the movie generation to the edge,
or you need to build bigger pipes across the world. I'm not sure how
feasible either option is.

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

^ permalink raw reply	[flat|nested] 120+ messages in thread
[parent not found: <mailman.2877.1714641707.1074.starlink@lists.bufferbloat.net>]
* Re: [Starlink] It's the Latency, FCC
@ 2024-05-01 16:35 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-05-01 16:35 UTC (permalink / raw)
  To: starlink

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

I always find this list interesting to get updated on what is happening
with policies for Internet access deployments in the U.S. and elsewhere,
and what role is Starlink getting.

Starlink was conceived for having Internet access fast in remote areas, for
leisure, surprisingly fast for SATCOM standards, even compared to 4G/5G
mobile networks and DSL, almost like having FTTH. Then, it has become a
tactical communications network, with military applications that cannot be
ignored, triggering the development of IRIS2 in Europe (as OneWeb was
already owned by the UK, not in the EU nowadays).

In Spain, telco operators are switching off the copper network, no more
dial-up or DSL possible, moving exclusively to FTTH, 5G NSA and then there
is GEO satellite Internet access (subsidized by Government) for rural
areas, now at 200 Mbit/s. I think that there is no fixed Internet access
below 100 Mbit/s in the market, nowadays in Spain.

Latest movement I have seen is a drastic price reduction in Spain for the
Starlink Basic option, becoming cheaper than the Government subsidized GEO
Internet access (via Hispasat): 29 euro/month vs. 35 euro/month.
https://www.starlink.com/es/service-plans

Regards,

David F.

Date: Wed, 1 May 2024 15:13:14 +0000
From: Colin_Higbie <CHigbie1@Higbie.name>
To: David Lang <david@lang.hm>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Itʼs the Latency, FCC
Message-ID:
        <
MN2PR16MB3391FCBE610E11DF886FE0A6F1192@MN2PR16MB3391.namprd16.prod.outlook.com
>

Content-Type: text/plain; charset="utf-8"

David,

I'm not thinking about an urban rollout. My default perspective is rural.
The closest house to my farm is about a half mile away, only 330 people in
our whole town, which is geographically large. This is what drove my need
for Starlink in the first place – I had previously been paying $330/mo for
a bunch of DSL lines and 2 T-1s aggregated via an SD-WAN solution. Starlink
gave me much more download bandwidth and a hair more on upload, lower
latency, vastly improved reliability, and cut my costs by almost 3/4
(72.7%).

Then, in a surprise move, our power company rolled out a fiber network to
its rural customers, which is even better on bandwidth at 1Gbps both up and
down and provides comparable latency. I can say as a user that at
comparable latency, the UX boost with 1Gbps U and D compared with
Starlink's connection is dramatic for work. Large file uploads and
downloads are nearly instant, significantly increasing productivity. I can
also now video conference without worrying about disruption on the sending
signal due to family members being on the Internet at the same time. I have
also changed the settings on family gaming and PC systems so they can watch
YouTube at full resolution, where with Starlink, to avoid congestion on
bandwidth (not bufferbloat) if everyone happened to be using the Internet
at the same time, I had locked everyone else down to 480p or 720p streams.

My goal in saying that it's better to do a slower rollout if needed to
provide at least 25Mbps is to maximize end user experience and be efficient
with constructions costs. This is my perspective because it's the
perspective ISPs will have and therefore the necessary mindset to influence
them. It's the perspective I have, and everyone who runs a business has,
when people approach us telling us how to run our businesses. When you
charge them waving data like an academic, an approach you appear to use in
many of these emails (though to be fair, maybe you're different with this
mailing list than you would be during a pitch to government or industry),
you only alienate the audience and reduce the likelihood of anything
getting done.

In rural areas in the U.S., the long term harm to rushing out low-bandwidth
solutions is significant. It would be better for them to have nothing new
for another year or two and then get a 25+ Mbps connection that get a
10Mbps connection now, then get no upgrades for another 10-15 years, which
is the likely outcome for many. Keep in mind that in the U.S., nearly all
residents already have at least dial-up access for email and other
trickle-in connections and most have some form of DSL, even if sub-1Mbps.
Of course, now there is also Starlink, though w/Starlink, cost can be a
barrier for some.

However, and perhaps this is what you meant, I am admittedly thinking about
this as a U.S. citizen. I would acknowledge that in other parts of the
world where it's a not a matter of just waiting an extra couple of years to
get an upgrade from dial-up or DSL, the situation may be different.
Infrastructure costs at 25Mbps could be prohibitive in those markets, where
a single feed to a village could be a significant upgrade from their
current state of no Internet access for dozens or hundreds of miles. I
accept my pushing for a recognition of 25Mbps floor for the top speed
offered refers to 1st world markets where we have the luxury of being able
to do it right in the first place to save money in the long run.

 - Colin

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

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [Starlink] It's the Latency, FCC
@ 2024-05-01  8:41 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-05-01  8:41 UTC (permalink / raw)
  To: starlink


[-- Attachment #1.1: Type: text/plain, Size: 626 bytes --]

Nobody watches 4K on the mobile when using TikTok, which reduces the
quality at peak hours to save bandwidth (money).

See attached picture.

Date: Tue, 30 Apr 2024 17:40:20 -0700 (PDT)
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
Message-ID: <4206ro7p-213r-so60-14s7-r23n39009p6p@ynat.uz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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

[-- Attachment #1.2: Type: text/html, Size: 1178 bytes --]

[-- Attachment #2: VideoResolutionsMobileTikTok.png --]
[-- Type: image/png, Size: 258166 bytes --]

^ permalink raw reply	[flat|nested] 120+ messages in thread
[parent not found: <mailman.2785.1714507537.1074.starlink@lists.bufferbloat.net>]
[parent not found: <mailman.2779.1714503924.1074.starlink@lists.bufferbloat.net>]
[parent not found: <mailman.2775.1714488970.1074.starlink@lists.bufferbloat.net>]
[parent not found: <mailman.2769.1714483871.1074.starlink@lists.bufferbloat.net>]
* Re: [Starlink] It’s the Latency, FCC
@ 2024-04-30  9:54 David Fernández
  0 siblings, 0 replies; 120+ messages in thread
From: David Fernández @ 2024-04-30  9:54 UTC (permalink / raw)
  To: starlink

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

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-broadcast-and-broadband-television

Regards,

David

Date: Mon, 29 Apr 2024 19:16:27 -0700 (PDT)
From: David Lang <david@lang.hm>
To: Colin_Higbie <CHigbie1@Higbie.name>
Cc: David Lang <david@lang.hm>,  "starlink@lists.bufferbloat.net"
        <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] Itʼs the Latency, FCC
Message-ID: <srss5qrq-7973-5q87-823p-30pn7o308608@ynat.uz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Amazon, youtube set explicitly to 4k (I didn't say HDR)

David Lang

On Tue, 30 Apr 2024, Colin_Higbie wrote:

> Date: Tue, 30 Apr 2024 01:30:21 +0000
> From: Colin_Higbie <CHigbie1@Higbie.name>
> To: David Lang <david@lang.hm>
> Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
> Subject: RE: [Starlink] Itʼs the Latency, FCC
>
> Was that 4K HDR (not SDR) using the standard protocols that streaming
services use (Netflix, Amazon Prime, Disney+, etc.) or was it just some
YouTube 4K SDR videos? YouTube will show "HDR" on the gear icon for content
that's 4K HDR. If it only shows "4K" instead of "HDR," then means it's SDR.
Note that if YouTube, if left to the default of Auto for streaming
resolution it will also automatically drop the quality to something that
fits within the bandwidth and most of the "4K" content on YouTube is
low-quality and not true UHD content (even beyond missing HDR). For
example, many smartphones will record 4K video, but their optics are not
sufficient to actually have distinct per-pixel image detail, meaning it
compresses down to a smaller image with no real additional loss in picture
quality, but only because it's really a 4K UHD stream to begin with.
>
> Note that 4K video compression codecs are lossy, so the lower quality the
initial image, the lower the bandwidth needed to convey the stream w/o
additional quality loss. The needed bandwidth also changes with scene
complexity. Falling confetti, like on Newy Year's Eve or at the Super Bowl
make for one of the most demanding scenes. Lots of detailed fire and
explosions with fast-moving fast panning full dynamic backgrounds are also
tough for a compressed signal to preserve (but not as hard as a screen full
of falling confetti).
>
> I'm dubious that 8Mbps can handle that except for some of the simplest
video, like cartoons or fairly static scenes like the news. Those scenes
don't require much data, but that's not the case for all 4K HDR scenes by
any means.
>
> It's obviously in Netflix and the other streaming services' interest to
be able to sell their more expensive 4K HDR service to as many people as
possible. There's a reason they won't offer it to anyone with less than
25Mbps – they don't want the complaints and service calls. Now, to be fair,
4K HDR definitely doesn’t typically require 25Mbps, but it's to their
credit that they do include a small bandwidth buffer. In my experience
monitoring bandwidth usage for 4K HDR streaming, 15Mbps is the minimum if
doing nothing else and that will frequently fall short, depending on the 4K
HDR content.
>
> Cheers,
> Colin
>
>
>
> -----Original Message-----
> From: David Lang <david@lang.hm>
> Sent: Monday, April 29, 2024 8:40 PM
> To: Colin Higbie <colin.higbie@scribl.com>
> Cc: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Itʼs the Latency, FCC
>
> hmm, before my DSL got disconnected (the carrier decided they didn't want
to support it any more), I could stream 4k at 8Mb down if there wasn't too
much other activity on the network (doing so at 2x speed was a problem)
>
> David Lang
>
>
> On Fri, 15 Mar 2024, Colin Higbie via Starlink wrote:
>
>> Date: Fri, 15 Mar 2024 18:32:36 +0000
>> From: Colin Higbie via Starlink <starlink@lists.bufferbloat.net>
>> Reply-To: Colin Higbie <colin.higbie@scribl.com>
>> To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>>
>>> I have now been trying to break the common conflation that download
"speed"
>>> means anything at all for day to day, minute to minute, second to
>>> second, use, once you crack 10mbit, now, for over 14 years. Am I
>>> succeeding? I lost the 25/10 battle, and keep pointing at really
>>> terrible latency under load and wifi weirdnesses for many existing
100/20 services today.
>>
>> While I completely agree that latency has bigger impact on how
responsive the Internet feels to use, I do think that 10Mbit is too low for
some standard applications regardless of latency: with the more recent
availability of 4K and higher streaming, that does require a higher minimum
bandwidth to work at all. One could argue that no one NEEDS 4K streaming,
but many families would view this as an important part of what they do with
their Internet (Starlink makes this reliably possible at our farmhouse). 4K
HDR-supporting TV's are among the most popular TVs being purchased in the
U.S. today. Netflix, Amazon, Max, Disney and other streaming services
provide a substantial portion of 4K HDR content.
>>
>> So, I agree that 25/10 is sufficient, for up to 4k HDR streaming. 100/20
would provide plenty of bandwidth for multiple concurrent 4K users or a 1-2
8K streams.
>>
>> For me, not claiming any special expertise on market needs, just my own
personal assessment on what typical families will need and care about:
>>
>> Latency: below 50ms under load always feels good except for some
>> intensive gaming (I don't see any benefit to getting loaded latency
>> further below ~20ms for typical applications, with an exception for
>> cloud-based gaming that benefits with lower latency all the way down
>> to about 5ms for young, really fast players, the rest of us won't be
>> able to tell the difference)
>>
>> Download Bandwidth: 10Mbps good enough if not doing UHD video
>> streaming
>>
>> Download Bandwidth: 25 - 100Mbps if doing UHD video streaming,
>> depending on # of streams or if wanting to be ready for 8k
>>
>> Upload Bandwidth: 10Mbps good enough for quality video conferencing,
>> higher only needed for multiple concurrent outbound streams
>>
>> So, for example (and ignoring upload for this), I would rather have
latency at 50ms (under load) and DL bandwidth of 25Mbps than latency of 1ms
with a max bandwidth of 10Mbps, because the super-low latency doesn't solve
the problem with insufficient bandwidth to watch 4K HDR content. But, I'd
also rather have latency of 20ms with 100Mbps DL, then latency that exceeds
100ms under load with 1Gbps DL bandwidth. I think the important thing is to
reach "good enough" on both, not just excel at one while falling short of
"good enough" on the other.
>>
>> Note that Starlink handles all of this well, including kids watching
YouTube while my wife and I watch 4K UHD Netflix, except the upload speed
occasionally tops at under 3Mbps for me, causing quality degradation for
outbound video calls (or used to, it seems to have gotten better in recent
months – no problems since sometime in 2023).
>>
>> Cheers,
>> Colin
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>

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

^ permalink raw reply	[flat|nested] 120+ messages in thread
[parent not found: <mailman.2495.1710610618.1074.starlink@lists.bufferbloat.net>]
[parent not found: <mailman.11.1710518402.17089.starlink@lists.bufferbloat.net>]
* [Starlink] It’s the Latency, FCC
@ 2024-03-15  3:53 Larry Press
  2024-03-15  5:33 ` Dave Taht
  0 siblings, 1 reply; 120+ messages in thread
From: Larry Press @ 2024-03-15  3:53 UTC (permalink / raw)
  To: starlink


[-- Attachment #1.1: Type: text/plain, Size: 61 bytes --]

https://circleid.com/posts/20231211-its-the-latency-fcc



[-- Attachment #1.2: Type: text/html, Size: 773 bytes --]

[-- Attachment #2: PageLoadVsLatency.png --]
[-- Type: image/png, Size: 48607 bytes --]

[-- Attachment #3: NetflixSppedTable.png --]
[-- Type: image/png, Size: 64224 bytes --]

^ permalink raw reply	[flat|nested] 120+ messages in thread
end of thread, other threads:[~2024-06-07  7:51 UTC | newest]

Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
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-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.2775.1714488970.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:12 ` 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     ` [Starlink] It?s " David Lang
     [not found] <mailman.2769.1714483871.1074.starlink@lists.bufferbloat.net>
2024-04-30 14:00 ` [Starlink] It’s " 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox