https://bugs.kde.org/show_bug.cgi?id=474135
--- Comment #17 from [email protected] --- > For devices on decently slow, but not massively slow, networks, couldn't > parallel downloads increase performance, though? More is not necessarily better. More parallel connections = more TCP handshakes, more DNS lookups, more packets through the network, every lost packet must be retransmitted etc. Lost packets are infinitely worse on wireless compared to wired connections. One sequential stream is easier for every single link in the chain, and there's always a bottleneck, be it CPU speed, LAN throughput, hard drive IOPS, internet connection speed etc. > Insofar as enough bandwidth > is available, it means that the packages are downloaded faster, so that the > network can return to a less-saturated state quicker. In theory. But in practice what the user has observed is that sequential downloads (via flatpak command line) present no issue, whereas parallel downloads (via Discover GUI) break things. > I know that, for me, having the update process last longer would, in > practice, be more of a problem for me than a quick, high-bandwidth download. Is it that much of an issue though? I would prefer to have an update take a little bit longer without breaking things than try to run as fast as possible and possibly max out my CPU, bog down the WI-FI etc. -- You are receiving this mail because: You are watching all bug changes.
