David, Yes, poor word choice on my part to say "nearly all TVs sold today are 4K TVs." I was thinking of 4K sets in contrast to the tiny % of 8K sets when I wrote that to make the point that 8K is not about to become a market standard like 4K. Better to have said, "The market for 8K tv sets is tiny." You are correct that there are still many 1080p sets also sold at the low end.
But this misstep on my part is immaterial to the core point. I'm not sure if you are just (fairly and correctly) calling me out for that mistake or if you actually disagree that ISPs should invest (if needed) to offer at least 25Mbps service to support 4K HDR streaming, in which case you fundamentally misunderstand the market for Internet usage. This is a largely black and white issue: there are a significant # of users who need 4K streaming support. Period. This is a market standard, like 91 octane gas, 802.11ax Wi-Fi, skim (0%) milk, 50 SPF sunblock, and 5G phones. The fact that not everyone uses one of those market-established standards does not mean that each is not an important standard with a sizable market cohort that merits support. 25Mbps for 4K HDR streaming is one such standard. That's not my opinion. That's a market-established fact and the only reason I posted here – to ensure this group has that information so that you can be more effective in presenting your latency arguments and solutions to the ISPs. There is no conflict between the need to support 25Mbps Internet and this group's goal of reducing latency at load. On the other hand, you lose credibility and won't be taken seriously by your target audience if you disregard the importance of the need for every ISP rolling out a new plan to at least offer a 25Mbps bandwidth level of support. Arguing with me that not everyone cares about 4K is like arguing with the supermarket that they shouldn't carry skim milk or your local gas station that they should drop 91 (or 93) octane or your local Best Buy that they don't need to waste shelf space with Wi-Fi 6e or 7 routers because not everyone uses those. It's purely counterproductive and prevents your others points from being heard. On gaming, and I suspect you know this, there are different use cases of Internet for gaming. There is competitive gaming, where bandwidth is largely meaningless (provided it is at a sufficient level of at least a few Mbps) because the games are played locally with only modest data exchanges to share location and status information. For those games, latency is king. In the extreme cases there, even 10ms latency may be pushing the limits of what gamers can tolerate, but sub 60ms or 50ms is usually sufficient (strategy and turn-based games are fine with much higher latencies, first-person shooters or driving games require lower latencies). However, there is also a growing, but still relatively niche, game streaming market. This includes services like Xbox Cloud Gaming, GeForce Now, and Amazon Luna. GeForce Now requires 45Mbps minimum connection for 4K gaming (same latency notes as above depending on the game genre). The higher bandwidth here compared to 25Mbps for video streaming services is due to the higher framerate and less lossy compression used for to preserve the HUD which must be perfectly sharp for gaming. However, note that I would not say that this is a needed standard like support for 4K HDR streaming. Unlike 4K video streaming which is mass market, 4K game streaming is extremely niche. Xbox Cloud Gaming doesn't even offer 4K streaming at present (but they likely will add it within the next year or two and they do support 60fps at 1080p, which is double the framerate of video streaming that only runs at 30fps). You also commented on upload bandwidth. If uploading large files, obviously higher is better, but there's no clear market requirement on this. Generally (but not always), with asymmetrical connections, a higher download bandwidth corresponds to a higher upload bandwidth. That's why I said that higher bandwidth does have advantages for remote work. I am not asserting that all remote workers need that, but clearly higher bandwidth and lower latency are both better than the alternatives. For my remote work (and 4K video streaming), Starlink's download bandwidth (70-200Mbps) was always plenty, more than I need. However, Starlink's upload bandwidth (originally 2-10Mbps) used to frequently fall short of my needs for video conferencing while uploading media files. Improvements over the past year had largely resolved that where I saw stable upload bandwidth between 12-20Mbps. I confess that I have shifted to only keeping Starlink for emergency backup because we recently gained access to fiber with a symmetric 1Gbps upload and download and negligible bufferbloat (a real surprise when our power company deployed that out here in the country in rural NH where we can't even get cable TV, yeah the power company, not the telephone or cable TV provider). They also offer up to 2.5Gbps in both directions and while my LAN hardware supports 2.5Gbps throughout, it's not worth paying anything extra to go beyond 1Gbps for me. -----Original Message----- From: David Lang <da...@lang.hm> Sent: Tuesday, April 30, 2024 8:52 PM To: Colin Higbie <colin.hig...@scribl.com> Cc: starlink@lists.bufferbloat.net Subject: Re: [Starlink] Itʼs the Latency, FCC On Tue, 30 Apr 2024, Colin Higbie via Starlink wrote: > Great points. I mostly agree and especially take your point on lower latency > increasing the effective "range" of remote sites/services that become > accessible based on their own added latency due to distance. That's a great > point I was not considering. As an American, I tend to think of everything as > "close enough" that no sites have latency problems, but you are clearly > correct that's not fair to project as a universal perspective, especially to > users in other countries who have to reach servers in the U.S. (and I'm sure > some users in the U.S. also need to reach servers in other countries too, > just not very often in my experience). > > However, two points of slight disagreement, or at least desire to get > in the last word ;-) > the fact remains that 4K services are a standard and a growing one as > nearly all TVs sold today are 4K TVs. really? then why was walmart still have almost 200 tv models at 1080p or below > 2. Using a Remote Desktop can be a great solution to solve some of the > bandwidth problems if the files can start and end on the remote systems. > However, even then it's a very specific solution and not always an option. > Just to use myself as an example, I do media work with a team of > people. We are geographically dispersed. There are common servers for > storing the data (OneDrive and Amazon S3 and RDS and our own custom > Linux systems to run various media adjustments automatically), but they are > not local to anyone. > The bulk of the work must be done locally. I suppose you could work on > a media file via a remote desktop function with sufficient bandwidth > to provide real-time 4K or 5K streaming and super low latency (often > need to make changes in fraction-of-a-second increments, hit > pause/play at exactly the right moment, etc.). But even if you had the > high speeds already to do that remotely, you would still need to > upload the file in the first place from wherever you are with the > microphones and cameras. Raw video files, which are still uncompressed > or, at best, compressed using lossless compression, are HUGE (many > GBs). Even raw straight audio files are typically in the hundreds of > MBs and sometimes a few GBs. Further, if the mics and cameras are > connected directly to the computer, there are many real-time changes that can > be made DURING the recording, which would be impossible on a remote system. hardly your typical remote worker. We are not saying that nobody needs higher bandwidth, just that pointing at things like this and saying that the minimum connection should support them is not reasonable. > Same applies for anyone who wants to post to YouTube. Many will to do > most of their video editing locally before uploading to YouTube. Those > that do their editing in the cloud still have to upload it to the > cloud. An active YouTuber might upload multiple many-GB video files every day. you do realize that a lot of '25Mb connections' only upload at 10Mb or slower, right? I pay for a 600Mb cablemodem and that only gives me 30Mb upload? > Similarly, for gaming, yes, with high enough bandwidth and low-enough > latency, you could pay a monthly fee for a game service and get decent > graphics and latency, but it's still not as good as a high-end system > locally (or if you just want to avoid the monthly fee). There's always > a mushiness to the latency and generally some compression artifacts in > the graphics that are not there when the screen is being rendered > locally with no compression using a multi-Gbps connection between system and > monitor/TV. so let gamers pay for higher bandwidth if they need it? but is the problem really bandwidth, or is it latency being papered over with bandwidth? > In another case, we built an electronic medical records system for > physicians. > The performance using remote desktop to a virtual machine even on the > same LAN was too slow. It wasn't unusably slow, but it was slow enough > that users who had opted that route to save money routinely upgraded > to more performant Windows tablets for the performance boost of the > native UI. To be fair, this was back at 820.11n, when Wi-Fi LAN speeds > topped out at about 40Mbps from most locations in the offices (higher > if really close to the AP, but those ideal conditions were rare). When > the tablets the doctors used ran the UI natively, not as dumb > terminals, performance UX and customer feedback was far better. When > using a pen/stylus, even a 20ms lag is enough to make the writing feel > wrong. A few tens of ms to redraw the screen when trying to shuttle > through pages of notes in a few seconds to skim for a specific piece of data > is painfully slow. again, not a minimal home user experience. David Lang > Cheers, > Colin > > _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
