From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A5C793B29D for ; Tue, 30 Apr 2024 10:45:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1714488317; x=1715093117; i=moeller0@gmx.de; bh=nAPKdqTU7UjPfH32Q3D2HzKKi8wvKnTfBOI4uYf+RS8=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=Nf8vvibcO8vEl4W5tonyK1M1S4M+ICYdnaaKJZwelG5oATFYGi83ITAwlDE+oc55 W/SQdHzxyRitPvQdSyLuUKwGD6wIoJ4tFVTTDmjL0ZwWruxipmyxU7h15VahubV8E hMJwqssm9n2yjyGmhUp1NMX92bYGkqr3UBjKq3WuxEv2wX+y0EUxn5JkH8qMwIh6w YgpwHkoM5ZT6RNnqNHTBHxrI5AALZzMK0N8liUGOZVahjldEtHPA9McJ7vqC4ldio B0jKzeWZg7X+Yvjhq6GjXdA8ic2yP1S168zpvDc+NF2ip/5KqU3fPaPwu6j4vbHmU YIeIkn+T4AAUVMDHGA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M6UZv-1rzMoe3IvR-006sMl; Tue, 30 Apr 2024 16:45:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Sebastian Moeller In-Reply-To: <727b07d9-9dc3-43b7-8e17-50b6b7a4444a@gmail.com> Date: Tue, 30 Apr 2024 16:45:07 +0200 Cc: Hesham ElBakoury via Starlink Content-Transfer-Encoding: quoted-printable Message-Id: References: <727b07d9-9dc3-43b7-8e17-50b6b7a4444a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Provags-ID: V03:K1:iYF4fLtPkmCvrCV///Ok+toYrqwPl7jM5wEi7NwhYcj/Lrpa7Fr nm1ucVsqvGXGmVOUKU6+9/ro4LL16ftvc1b7soJgjrXk3+K0YrehjT1KgZIUnolyAVRQ/lE rFljFt49VbuobMSl0q3iJRMravn/ltKwnA/KZS0K6mTG76/vEsZEf8KxKTB66DeUSrneWpi X2b+Xbat4GppVrFjj4G/Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:O2Qselfjy9Q=;DVLbAPDmDsydXH4IZ6Qten2JyHU fRixQWEZAmxp781BPu4YVNpku9j+9yF1LTg79SRBVfYVp1sfTV7oPmKoe4pWGckw9d+ZSTGmU j106t6N+jYliaaPAuaTdLKaeyCmvPB1iLeS1e/xumNjU1uo/jSLr5SNPUGOi0mFEQzOjOTmMM 56QZwbA0qco5sD4hh1qTKQk9Jmph8PWqc+2v64lOOYt7RW3bScW0pIoQqf3Vmdv/Zfr2oVYU6 34YD130fEQPi37HKp1Oav9O8r0bPrhep0xheNv5FqbecMZK8oQuq9m+iIWZUEvHjIJlPdpwde liiVAID8lEoGDfqcXVpSyj7XhMYlARHqD2sPPkdbkTrnGEp7jcnB7OGKHHMjZNPFB6dGP/ETV 9b/+V/eLcOrAH7ch11dilDJe5MusHWccGwMmhl6Y7ezuxHh/2RVggLr0GJjloK+IRP+A00yQN TIXpkfJuMutYIBultZom0p59uf7R5l8fWNZXW5qvgk+lkE28/nR3k7DXD7D7+qHWktTVuWDdr ImIb+d+tphK9jJybGy2PvrW54diIXm++oPKBxVfFsurGEiYIMCXEWKAXRI5+domVHO0THwnqg SwQutlYuyDBHRq4/32N6D54ubqMBOWfSIv8+JOT13Jc0CfoMp9fQ8fGRRut9RG226++3Q2YU6 /NLvrcDIvcVW3vEgBgimMjN16yQkuDURi2Rmj4BEJsXSqHRtCiaqbT7FhVJYToghIfb8VEP8D B9h+WtNENB8Hqq4oIbfXdXEhKkGhVVMjhS2zUQPXbFGTkbqiKRWBfUFWlswh8VEx0EMk220QU 9DfDsz5dW1u7wgCUsobpJXAZg0aHpb3Q585k4FPo2fupc= Subject: Re: [Starlink] =?utf-8?q?It=E2=80=99s_the_Latency=2C_FCC?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2024 14:45:20 -0000 Hi Alexandre, > On 30. Apr 2024, at 16:40, Alexandre Petrescu = wrote: >=20 >=20 > Le 30/04/2024 =C3=A0 16:32, Sebastian Moeller a =C3=A9crit : >> Hi Alexandre, >>=20 >>=20 >>=20 >>> On 30. Apr 2024, at 16:25, Alexandre Petrescu via Starlink = wrote: >>>=20 >>> 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=3DhHwjceFcF2Q 'enhance'... >>=20 >>> 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... >=20 > 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. >=20 > (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-clo= ud-migrations.html so this is more than just a concept... >=20 > Alex >=20 >>=20 >>=20 >>> 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 =C3=A0 16:00, Colin_Higbie via Starlink a =C3=A9crit : >>>> David Fern=C3=A1ndez, 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. >>>>=20 >>>> 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=C3=A1ndez'= point that Spain independently reached the same conclusion as the US = streaming services of 25Mbps requirement for 4K. >>>>=20 >>>> 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=E2=80=99t = 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=E2=80=99t. >>>>=20 >>>> 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=E2=80=99s good enough = for most people to not notice the difference. I don=E2=80=99t see much = push in the foreseeable future for programming beyond UHD (4K + HDR). = That=E2=80=99s not to say never, but there=E2=80=99s no real benefit to = it with current camera tech and screen sizes. >>>>=20 >>>> Conclusion: for video streaming needs over the next decade or so, = 25Mbps should be appropriate. As David Fern=C3=A1ndez 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. >>>>=20 >>>> Cheers, >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Starlink 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 >>>>=20 >>>>=20 >>>>=20 >>>> Message: 2 >>>> Date: Tue, 30 Apr 2024 11:54:20 +0200 >>>> From: David Fern=C3=A1ndez >>>> To: starlink >>>> Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC >>>> Message-ID: >>>> = >>>> Content-Type: text/plain; charset=3D"utf-8" >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Full HD video (1080p) requires 10 Mbit/s. >>>>=20 >>>> 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). >>>>=20 >>>> Then, 8K will come, eventually, requiring a minimum of ~32 Mbit/s: >>>> = https://dvb.org/news/new-generation-of-terrestrial-services-taking-shape-i= n-europe >>>>=20 >>>> 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 >>>>=20 >>>> Regards, >>>>=20 >>>> David >>>>=20 >>>> Date: Mon, 29 Apr 2024 19:16:27 -0700 (PDT) >>>> From: David Lang >>>> To: Colin_Higbie >>>> Cc: David Lang , "starlink@lists.bufferbloat.net" >>>> >>>> Subject: Re: [Starlink] It=CA=BCs the Latency, FCC >>>> Message-ID: >>>> Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed" >>>>=20 >>>> Amazon, youtube set explicitly to 4k (I didn't say HDR) >>>>=20 >>>> David Lang >>>>=20 >>>> On Tue, 30 Apr 2024, Colin_Higbie wrote: >>>>=20 >>>>=20 >>>>> Date: Tue, 30 Apr 2024 01:30:21 +0000 >>>>> From: Colin_Higbie >>>>> To: David Lang >>>>> Cc: "starlink@lists.bufferbloat.net" = >>>>> Subject: RE: [Starlink] It=CA=BCs the Latency, FCC >>>>>=20 >>>>> Was that 4K HDR (not SDR) using the standard protocols that = streaming >>>>>=20 >>>> 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. >>>>=20 >>>>> Note that 4K video compression codecs are lossy, so the lower = quality >>>>> the >>>>>=20 >>>> 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). >>>>=20 >>>>> I'm dubious that 8Mbps can handle that except for some of the = simplest >>>>>=20 >>>> 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. >>>>=20 >>>>> It's obviously in Netflix and the other streaming services' = interest >>>>> to >>>>>=20 >>>> 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 =E2=80=93 they don't want the complaints and service = calls. Now, to be fair, 4K HDR definitely doesn=E2=80=99t 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. >>>>=20 >>>>> Cheers, >>>>> Colin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: David Lang >>>>> Sent: Monday, April 29, 2024 8:40 PM >>>>> To: Colin Higbie >>>>> Cc: starlink@lists.bufferbloat.net >>>>> Subject: Re: [Starlink] It=CA=BCs the Latency, FCC >>>>>=20 >>>>> hmm, before my DSL got disconnected (the carrier decided they = didn't >>>>> want >>>>>=20 >>>> 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) >>>>=20 >>>>> David Lang >>>>>=20 >>>>>=20 >>>>> On Fri, 15 Mar 2024, Colin Higbie via Starlink wrote: >>>>>=20 >>>>>=20 >>>>>> Date: Fri, 15 Mar 2024 18:32:36 +0000 >>>>>> From: Colin Higbie via Starlink >>>>>> Reply-To: Colin Higbie >>>>>> To: "starlink@lists.bufferbloat.net" = >>>>>> Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC >>>>>>=20 >>>>>>=20 >>>>>>> I have now been trying to break the common conflation that = download >>>>>>>=20 >>>> "speed" >>>>=20 >>>>>>> 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 >>>>>>>=20 >>>> 100/20 services today. >>>>=20 >>>>>> While I completely agree that latency has bigger impact on how >>>>>>=20 >>>> 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. >>>>=20 >>>>>> So, I agree that 25/10 is sufficient, for up to 4k HDR streaming. >>>>>> 100/20 >>>>>>=20 >>>> would provide plenty of bandwidth for multiple concurrent 4K users = or a 1-2 8K streams. >>>>=20 >>>>>> For me, not claiming any special expertise on market needs, just = my >>>>>> own >>>>>>=20 >>>> personal assessment on what typical families will need and care = about: >>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> Download Bandwidth: 10Mbps good enough if not doing UHD video >>>>>> streaming >>>>>>=20 >>>>>> Download Bandwidth: 25 - 100Mbps if doing UHD video streaming, >>>>>> depending on # of streams or if wanting to be ready for 8k >>>>>>=20 >>>>>> Upload Bandwidth: 10Mbps good enough for quality video = conferencing, >>>>>> higher only needed for multiple concurrent outbound streams >>>>>>=20 >>>>>> So, for example (and ignoring upload for this), I would rather = have >>>>>>=20 >>>> 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. >>>>=20 >>>>>> Note that Starlink handles all of this well, including kids = watching >>>>>>=20 >>>> 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 =E2=80=93 no problems since sometime in = 2023). >>>>=20 >>>>>> Cheers, >>>>>> Colin >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Starlink mailing list >>>>>> Starlink@lists.bufferbloat.net >>>>>> https://lists.bufferbloat.net/listinfo/starlink >>>>>>=20 >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: = >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/starlink >>>>=20 >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink