491–500 of 763 posts
That explains a lot. Fair enough though > But it said viewers would still find the picture quality good. I beg to differ and I'm watching on my tablet in bed and it reminds me of the Avi files we used to watch on lan networks in the 90s.
Are you in Europe? I'd love to know how are services like Hulu or YouTube holding up?
Earlier quoted context omitted.
What is the advantage of this over simple old torrenting?
you can start watching immediately as it is downloading and it has a player built in, whereas the traditional torrent client needs to finish the video first and you need a separate video player.
Earlier quoted context omitted.
It's a made up problem. In Germany, journalists asked the network providers and they said everything is fine. Such a ridiculous and pointless thing to do by the EU. Especially since all the apps drop the quality automatically anyway if the connection is slow.
Here in Berlin my DSL connection has been awful since the social distancing began. And many of my friends have complained of similar problems. Frequent disconnections, broken up zoom calls. Though ironically the streaming has been fine from both Netflix & Amazon.
I've been having major internet issues lately (Seattle area), have had 4 techs come try to figure it out. Yesterday's tech finally correctly diagnosed the problem as happening before the connection reaches our home but was unsure of the cause. He called his supervisor to investigate, and they found that the capacity for our neighborhood's node was nearly at 100%, while ideally it should always be under 80%. Fortunate…
If you didn't know, that 80% number is probably the result of Little's Law. That's the result where if your demand is generated by a Poisson process, and your service has a queue, 80% utilization of the service is where the probability of an infinite queue starts to get really high. People Here's a nice blog post about the subject: https://www.johndcook.com/blog/2009/01/30/server-utilization...
If you have more control over or knowledge of your load, you can safely go higher than 80%.
Eg when I was working at Google we carefully tagged our RPC calls by how 'sheddable' they were. More sheddable load gets dropped first. Or, from the opposite perspective: when important load is safely under 100%, which it is almost all the time in a well-designed system, we can also handle more optional, more sheddable load.
As a further aside, parts of the financial system work on similar principles:
If you have a flow of income over time, like from a portfolio of offices you are renting out, you can take the first 80% of dollars that come in on average every month and sell that very steady stream of income off for a high price.
The rest of income is much choppier. Sometimes you fail to rent everything. Sometimes occupants fall behind on rent. Sometimes a building burns down.
So you sell the rest off as cheaper equity. It's more risky, but also has more upside potential.
The more stable and diversified your business, the bigger proportion you can sell off as expensive fixed income.
I've been having major internet issues lately (Seattle area), have had 4 techs come try to figure it out. Yesterday's tech finally correctly diagnosed the problem as happening before the connection reaches our home but was unsure of the cause. He called his supervisor to investigate, and they found that the capacity for our neighborhood's node was nearly at 100%, while ideally it should always be under 80%. Fortunate…
FWIW, the reason nodes typically don't get to 100% is due to something called WRED (Weighted Random Early Detection). As the outbound/inbound queue on your "node" approaches fullness, it randomly selects packets to drop. This signals TCP on the sender to back-off. The closer to full-ness it gets, the higher the probability (weight), so the sender knows to slow down to the slowest link's speed. I've written more about…
I wonder how TCP BBR would react here. If I understand it right, it wouldn't need RED to back off: the increased latency of buffers filling up would do that automatically. But BBR also wouldn't let the occasional dropped packet make it back off.
Earlier quoted context omitted.
This is also a reason to eat meat from animals fed food for people. In the bad times, slaughter the animals and eat the meat and the feed. It's changed my perspective on efficiency. There are some forms of inefficiency that can provide a buffer if something goes wrong.
That last line used to be highly internalized by Americans who lived thru the depression, WW 1 and 2, etc.
Though Americans were probably least affected by WW1 and WW2 of most war participants. Go ask some people in Russia for a better example.
Earlier quoted context omitted.
you can start watching immediately as it is downloading and it has a player built in, whereas the traditional torrent client needs to finish the video first and you need a separate video player.
Most torrent clients have a "download in sequential order as far as feasible" feature, addressing the first issue.
Also, always using sequential downloading isn't very good for the swarm; it means that disproportionately fewer seeders are available for the later chunks of a torrent.
I'd recommend downloading the first episode or two sequentially, but downloading the rest of the torrent normally (or perhaps just first/last parts first).
Earlier quoted context omitted.
You could think about the opposite way: it's good that Netflix was using so much bandwidth because it encouraged network upgrades. Now, when we need to use this capacity for something else, Netflix can flip a switch and it's available. Excess usage for luxuries like 4k video in good times is a way of preparing for bad times. Ideally we would treat hospital capacity the same way. In good times, everyone gets a private…
This is also a reason to eat meat from animals fed food for people. In the bad times, slaughter the animals and eat the meat and the feed. It's changed my perspective on efficiency. There are some forms of inefficiency that can provide a buffer if something goes wrong.
Eg flush toilets are a great time saver. But they use a lot of water.
If we had a drought tomorrow, we could switch to compost toilets. They are more hassle to use and maintain, but use basically no water.
Which one is more 'efficient' depends on the relative scarcity of water vs time.
Earlier quoted context omitted.
Sonarr and Radarr are 10x better.
New here. What's the difference between these two?