Maybe I just don't have the right combination of devices, and/or I absolutely need a wired connection. Regardless, I could not stop thinking how having physical media would avoid these drops.
Maybe I just don't have the right combination of devices, and/or I absolutely need a wired connection. Regardless, I could not stop thinking how having physical media would avoid these drops.
You do.
Also: Do not trust those "<four digits> mbps over wifi!" claims on marketing, they're all worthless horseshit. The numbers are derived from ideal conditions you would never find in the real world.
I do live in a house on a 1.5 acre parcel, so I'm not getting much congestion on the Wifi bands. Even so, I would regularly get 400Mb/s on Wifi 6 in our condo in NY where you could see 30 or more networks.
Whereas the wired ones upload their backups at full gigabit speed (~100MB/s including overhead), the wireless ones only ever upload at ~10MB/s. I might see it go up to ~30MB/s if I'm lucky, but we're talking pigs flying over blue moons.
The wireless machines range from "one wall away" to "other side of the bloody house", but they're all the same. Even if I get one one sitting right next to the router it won't do more than ~10MB/s. I'm also located in the middle of nowhere in terms of EMI, so the air is clear.
Wireless is bullshit. If you need speed, just run copper and save yourself the grief. You only use wireless when the convenience of not running copper and/or being mobile trumps the lack of speed and reliability.
If your backup mechanism is chatty/latency-sensitive, then that would affect overall throughput. Content streaming is neither of those things though.
>This obviously depends on your hardware and environment
This is the key point. If you have:
A high link rate client.
A high link rate access point.
Line of sight between the two, same room.
A low utilization and interference channel.
No one else heavily using your Wi-Fi.
Non-bad drivers for Wi-Fi.
Then TCP throughput of about 1/2 to 2/3 link rate is possible. 1200 Mbps link rate yields 600-700 Mbps speed tests. Some applications have small TCP windows so their throughput drops on 5 ms latency wireless versus <1 ms wired.
Yes if you plug you always get 920 Mbps throughput.
> https://electronics.sony.com/bravia-core
> 7: The Pure Stream™ feature requires an Internet speed of at least 43 Mbps. To enjoy at the highest speed of 80 Mbps, you need an Internet speed of 115 Mbps or faster. Ethernet (wired LAN) connections are limited to 100 Mbps due to the TV's product specifications. Therefore, to enjoy 80 Mbps with Pure Stream™ functionality, you need to connect to a Wi-Fi router that supports IEEE 802.11 ac/n (wireless LAN).
I find it roughly equal as things go.
The buffering thing genuinely confuses me. I get why it happens at a technical level, but the failure mode is odd. None of the content is live, just buffer the next 5 or 10 minutes to disk and have the player read from the disk buffer.
That should never buffer unless the network is degraded for a long while.
The full solution would be to just let people cache the entire video and watch directly from disk, but I believe that’s intolerable to the IP folks.
But the original DASH implementation was very aggressive about keeping a minimal buffer size and downgrading quality at the slightest hiccup. I was also on a not particularly great internet connection at the time, so I used to pause 720p at the start and let it buffer enough for uninterrupted playback, but YouTube's changes meant that just buffered like 15s and then shifted down to 360p. There were add-ons to force dash off to mitigate the problem but iirc YouTube was starting to make higher qualities dash exclusive.
Clearly someone at YouTube was optimising to reduce time-to-play and buffering but in a typical metrics driven approach, excluded the possibility that for some videos these were less bad problems than 360p videos. At that time I was watching a lot of let's plays and programming tutorials and most of the people were uploading content recorded and intended for 720p or 1080p, so unreadable text because of quality downgrades was a big problem for me at that time.
Nowadays I just brute force it by having comically excessive amounts of internet (2gbps ftth) so YouTube randomly deciding garbage quality is much rarer, but it still happens sometimes.
If you're using the web player and manually set the quality, it should never downgrade the quality during playback. If your connection is too slow it'll just pause while it tries to buffer
I don't know what kind of internet these Google engineers are working with, but for people on shared wifi, or in dense urban areas where there is a lot of interference, or tethering to a 4G phone, or sitting on a train, or a mountain, or using a VPN, or living in a country where the government messes with the traffic, it just isn't realistic to expect users to have a fat pipe that never drops out.
They get apps and updates now so I would’ve assumed some semi-reliable persistent storage. This really doesn’t even need to be persistent; resetting on reboot would be perfectly fine.
I’ve no doubt they would struggle to cache “real” 4K, but at the bitrate most of this 4K stuff is sent at, 1 GB of cache should be at least 5 minutes. Netflix recommends at least 15 Mbps for 4K streaming. Even doubled to 30Mbps, that’s ~4MB/s, or about 256 seconds of content cached per GB.