From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 044FF3CB38 for ; Mon, 18 Mar 2024 12:49:21 -0400 (EDT) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-41409fd8b6eso19795095e9.2 for ; Mon, 18 Mar 2024 09:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710780561; x=1711385361; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oFEK+i8yctXuECltCdfckksEXbmaACO2Tf1syTsw2zc=; b=WcFcfapoGvGD/E9/+04y10VYA17LasxqRhHYBshjaIOtTcBWcxmNnv37dvJnib0Vvc zxizEVWi70FJxitWBpDBIcmGX0WfyEy+whrRIMlwV8EK7UTZ4d/HSjIF+6/69KbSOvHr sLweR7YYffAlDv+8nQW9Kk3ny/MYa80Bz4QYDtMiPT1Pnlo4Xeq3/QdY6+xCowrwro71 yBrHA/f/YnvHQTL0Z5r6Ato696YmheOo72jENALChl0vOwvu13l0GVHZiCiarGVWVTuU 5eawkTUzKUmFoBWK8d/tnWV7BI3WU9zAqhUwvzqokxKj1iwcoro/XIguiaahnsFtQLcd 9qIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710780561; x=1711385361; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oFEK+i8yctXuECltCdfckksEXbmaACO2Tf1syTsw2zc=; b=F2TReVwJbF4TTVo4U0NJOl4nNsGUWU3ZbE9M/01onZ98Op5Q7oqyXO3wwgyRfV5ty9 I2qoT92JG+H6WZNxcFmknSdCWDah7ZwHoxqEKDk6RfQcbVDRvWX4SyZOjNFBX7QYz+Xt WUX8Jp7XTHr88PQYuTQgfVkzZ6BhKcFalC9yOjA7MV/djxkSUEEnKVW4tXVUFokAqeh/ j39BC5N7XdsEXDV2UEq4jf0q0jE+vWX8kCGY8XTccJUBqAJUCHzAvh7daxbiSPmvCJFp y/YR3ZHU8CZTFMPTGUgMSdmTXyzgqoVWiYSJaG4COZ/ds6k/JLYiGrUVc0qNwRz2lIIt DKcA== X-Gm-Message-State: AOJu0YzQ8TPvKduc0mZLavwnUlKgHia3+Ky4bzccKlMZpMtocvRC8nL0 Wu74dxaNDzkj1z9f4FHQ8hN2FrUAxKBZfP0LP5AXTav9WV3Dg/41jkSrRnU0zUjAT5qa8jo8NsS tW0ulf4pBpksAswyZfeMlonapatA= X-Google-Smtp-Source: AGHT+IHic7E99or7ZO32vjzKpkzdzC8y4Pg2oFY1wUvpQw67mysrNpxXK4ErTCpi/r+TB9cghFDZJcirb6BDnsRV768= X-Received: by 2002:a05:600c:68c8:b0:413:2a10:8a29 with SMTP id jd8-20020a05600c68c800b004132a108a29mr6450914wmb.13.1710780560429; Mon, 18 Mar 2024 09:49:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 18 Mar 2024 12:49:08 -0400 Message-ID: To: Colin_Higbie Cc: "starlink@lists.bufferbloat.net" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] =?utf-8?q?Sidebar_to_It=E2=80=99s_the_Latency=2C_FCC?= =?utf-8?q?=3A_Measure_it=3F?= 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: Mon, 18 Mar 2024 16:49:22 -0000 I am curious what the real world bandwidth requirements are for live sports, streaming? I imagine during episodes of high motion, encoders struggle. On Mon, Mar 18, 2024 at 12:42=E2=80=AFPM Colin_Higbie via Starlink wrote: > > To the comments and question from Dave Collier-Brown in response to my sa= ying that we test latency for UX and Alex on 8K screens, both of these seem= to take more academic view than I can address on what I view as commercial= subjects. By that, I mean that they seem to assume budget and market prefe= rences are secondary considerations rather than the primary driving forces = they are to me. > > From my perspective, end user/customer experience is ultimately the only = important metric, where all others are just tools to help convert UX into s= omething more measurable and quantifiable. To be clear, I fully respect the= importance of being able to quantify these things, so those metrics have v= alue, but they should always serve as ways to proxy the UX, not a target un= to themselves. If you're designing a system that needs minimal lag for test= ing your new quantum computer or to use in place of synchronized clocks for= those amazing x-ray photos of black holes, then your needs may be differen= t, but if you're talking about how Internet providers measure their latency= and bandwidth for sales to millions or billions of homes and businesses, t= hen UX based on mainstream applications is what matters. > > To the specifics: > > No, we (our company) don't have a detailed latency testing method. We tes= t purely for UX. If users or our QA team report a lag, that's bad and we wo= rk to fix it. If QA and users are happy with the that and negative feedback= is in other areas unrelated to lag (typically the case), then we deem our = handling of latency as "good enough" and focus our engineering efforts on t= he problem areas or on adding new features. Now, I should acknowledge, this= is largely because our application is not particularly latency-sensitive. = If it were, we probably would have a lag check as part of our standard auto= mated test bed. For us, as long as our application starts to provide our us= ers with streaming access to our data within a second or so, that's good en= ough. > > I realize good-enough is not a hard metric by itself, but it's ultimately= the only factor that matters to most users. The exception would be some ve= ry specific use cases where 1ms of latency delta makes a difference, like f= or some stock market transactions and competitive e-sports. > > To convert the nebulous term "good enough" into actual metrics that ISP's= and other providers can use to quantify their service, I stand by my prior= point that the industry could establish needed metrics per application. Vo= IP has stricter latency needs than web browsing. Cloud-based gaming has sti= ll stricter latency requirements. There would be some disagreement on what = exactly is "good enough" for each of those, but I'm confident we could reac= h numbers for them, whether by survey and selecting the median, by reported= complaints based on service to establish a minimum acceptable level, or by= some other method. I doubt there's significant variance on what qualifies = as good-enough for each application. > > 4K vs Higher Resolution as Standard > And regarding 4K TV as a standard, I'm surprised this is controversial. 4= K is THE high-end standard that defines bandwidth needs today. It is NOT 8K= or anything higher (similarly, in spite of those other capabilities you me= ntioned, CD's are also still 44.1kHz (48hKz is for DVD), with musical fidel= ity at a commercial level having DECREASED, not increased, where most sales= and streaming occurs using lower quality MP3 files). That's not a subjecti= ve statement; that is a fact. By "fact" I don't mean that no one thinks 8K = is nice or that higher isn't better, but that there is an established indus= try standard that has already settled this. Netflix defines it as 25Mbps. T= he other big streamers, Disney+, Max, and Paramount+ all agree. 25Mbps is h= igher than is usually needed for 4K HDR content (10-15Mbps can generally hi= t it, depending on the nature of the scenes where slow scenes with a lot of= solid background color like cartoons compress into less data than fast mov= ing visually complex scenes), but it it's a good figure to use because it i= ncludes a safety margin and, more importantly, it's what the industry has a= lready defined as the requirement. To me, this one is very black and white = and clear cut, even more so than latency. IF you're an Internet provider an= d want to claim that your Internet supports modern viewing standards for st= reaming, you must provide 25Mbps. I'm generally happy to debate anything an= d acknowledge other points of view are just as valid as my own, but I don't= see this particular point as debatable, because it's a defined fact by the= industry. It's effectively too late to challenge this. At best, you'd be f= ighting customers and content providers alike and to what purpose? > > Will that 25Mbps requirement change in the future? Probably. It will prob= ably go up even though 4K HDR streaming will probably be achievable with le= ss bandwidth in the future due to further improvements in compression algor= ithms. This is because, yeah, eventually maybe 8K or higher resolutions wil= l be a standard, or maybe there will be a higher bit depth HDR (that seems = slightly more likely to me). It's not at all clear though that's the case. = At some point, you reach a state where there is no benefit to higher resolu= tions. Phones hit that point a few years ago and have stopped moving to hig= her resolution displays. There is currently 0% of content from any major pr= ovider that's in 8K (just some experimental YouTube videos), and a person v= iewing 8K would be unlikely to report any visual advantage over 4K (SD -> H= D is huge, HD -> 4K is noticeable, 4K -> 8K is imperceptible for camera-rec= ording scenes on any standard size viewing experience). > > Where 8K+ could make a difference would primarily be in rendered content = (and the handful of 8K sets sold today play to this market). Standard camer= a lenses just don't capture a sharp enough picture to benefit from the extr= a pixels (they can in some cases, but depth of field and human error render= these successes isolated to specific kinds of largely static landscape sce= nes). If the innate fuzziness or blurriness in the image exceeds the size o= f a pixel, then more pixels don't add any value. However, in a rendered ima= ge, like in a video game, those are pixel perfect, so at least there it's p= ossible to benefit from a higher resolution display. But for that, even the= top of the line graphics today (Nvidia RTX 4090, now over a year old) can = barely generate 4K HDR content with path tracing active at reasonable frame= rates (60 frames per second), and because of their high cost, those make up= only 0.23% of the market as of the most recent data I've seen (this will o= bviously increase over time). > > I could also imagine AI may be able to reduce blurriness in captured vide= o in the future and sharpen it before sending it out to viewers, but we're = not there yet. For all these reasons, 8K will remain niche for the time bei= ng. There's just no good reason for it. When the Super Bowl (one of the fir= st to offer 4K viewing) advertises that it can be viewed in 8K, that's when= you know it's approaching a mainstream option. > > On OLED screens and upcoming microLED displays that can achieve higher co= ntrast ratios than LCD, HDR is far more impactful to the UX and viewing exp= erience than further pixel density increases. Current iterations of LCD can= 't handle this, even though they claim to support HDR, which has given many= consumers the wrong impression that HDR is not a big deal. It is not on LC= D's because they cannot achieve the contrast rations needed for impactful H= DR. At least not with today's technology, and probably never, just because = the advantages to microLED outweigh the benefits I would expect you could g= et by improving LCD. > > So maybe we go from the current 10-bit/color HDR to something like 12 or = 16 bit HDR. That could also increase bandwidth needs at the same 4K display= size. Or, maybe the next generation displays won't be screens but will be = entire walls built of microLED fabric that justify going to 16K displays at= hundreds of inches. At this point, you'd be close to displays that duplica= te a window to the outside world (but still far from the brightness of the = sun shining through). But there is nothing at that size that will be at con= sumer scale in the next 10 years. It's at least that far out (12+-bit HDR m= ight land before that on 80-110" screens), and I suspect quite a bit furthe= r. It's one thing to move to a larger TV, because there's already infrastru= cture for that. On the other hand, to go to entire walls made of a display = material would need an entirely different supply chain, different manufactu= rers, installers, cultural change in how we watch and use it, etc. Those ki= nds of changes take decades. > > Cheers, > Colin > > > Date: Sun, 17 Mar 2024 12:17:11 -0400 > From: Dave Collier-Brown > To: starlink@lists.bufferbloat.net > Subject: [Starlink] Sidebar to It=E2=80=99s the Latency, FCC: Measure it? > Message-ID: > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > On 2024-03-17 11:47, Colin_Higbie via Starlink wrote: > > > Fortunately, in our case, even high latency shouldn't be too terrible, = but as you rightly point out, if there are many iterations, 1s minimum late= ncy could yield a several second lag, which would be poor UX for almost any= application. Since we're no longer testing for that on the premise that 1s= minimum latency is no longer a common real-world scenario, it's possible t= hose painful lags could creep into our system without our knowledge. > > Does that suggest that you should have an easy way to see if you're unexp= ectedly delivering a slow service? A tool that reports your RTT to customer= s and an alert on it being high for a significant period might be something= all ISPs want, even ones like mine, who just want it to be able to tell a = customer "you don't have a network problem" (;-)) > > And the FCC might find the data illuminating > > --dave > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dave.collier-brown@indexexchange.com | -- Mark Twain > > > CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including= any and all attachments, contains confidential information intended only f= or the person(s) to whom it is addressed. Any dissemination, distribution, = copying or disclosure is strictly prohibited and is not a waiver of confide= ntiality. If you have received this telecommunication in error, please noti= fy the sender immediately by return electronic mail and delete the message = from your inbox and deleted items folders. This telecommunication does not = constitute an express or implied agreement to conduct transactions by elect= ronic means, nor does it constitute a contract offer, a contract amendment = or an acceptance of a contract offer. Contract terms contained in this tele= communication are subject to legal review and the completion of formal docu= mentation and are not binding until same is confirmed in writing and has be= en signed by an authorized signatory. > > > ------------------------------ > > Message: 2 > Date: Sun, 17 Mar 2024 18:00:42 +0100 > From: Alexandre Petrescu > To: starlink@lists.bufferbloat.net > Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC > Message-ID: > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > > Le 16/03/2024 =C3=A0 20:10, Colin_Higbie via Starlink a =C3=A9crit : > > Just to be clear: 4K is absolutely a standard in streaming, with that b= eing the most popular TV being sold today. 8K is not and likely won't be un= til 80+" TVs become the norm. > > I can agree screen size is one aspect pushing the higher resolutions to a= cceptance, but there are some more signs indicating that 8K is just round t= he corner, and 16K right after it. > > The recording consumer devices (cameras) already do 8K recording cheaply,= since a couple of years. > > New acronyms beyond simply resolutions are always ready to come up. HDR = (high dynamic range) was such an acronym accompanying 4K, so for 8K there m= ight be another, bringing more than just resolution, maybe even more dynami= c range, blacker blacks, wider gamut,-for goggles, etc. for a same screen s= ize. > > 8K and 16K playing devices might not have a surface to exhibit their enti= re power, but when such surfaces become available, these 8K and 16K playing= devices will be ready for them, whereas 4K no. > > A similar evolution is witnessed by sound and by crypto: 44KHz CD was eno= ugh for all, until SACD 88KHz came about, then DSD64, DSD128 and today DSD = 1024, which means DSD 2048 tomorrow. And the Dolby Atmos and > 11.1 outputs. These too dont yet have the speakers nor the ears to take= advantage of, but in the future they might. In crypto, the 'post-quantum'= algorithms are designed to resist brute force by computers that dont exist= publicly (a few hundred qubit range exists, but 20.000 qubit range comput= er is needed) but when they will, these crypto algos will be ready. > > Given that, one could imagine the bandwidth and latency by a 3D 16K > DSD1024 quantum-resistant ciphered multi-party visio-conference with glov= es, goggles and other interacting devices, with low latency over starlink. > > The growth trends (4K...) can be identified and the needed latency number= s can be projected. > > Alex > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink -- https://www.youtube.com/watch?v=3DN0Tmvv5jJKs Epik Mellon Podcast Dave T=C3=A4ht CSO, LibreQos