[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #9 from Ellie --- Created attachment 185673 --> https://bugs.kde.org/attachment.cgi?id=185673&action=edit The "fetching updates..." screen that doesn't seem to show any progress indicator of any kind. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #18 from Roke Julian Lockhart Beedell <[email protected]> --- I can't post my *full* response here, so you'll need to see https://discuss.kde.org/t/i-am-unable-to-post-a-comment-at-kde-bz/40509?u=rokejulianlockhart. Apologies; it's out of my control. What I can post is: (In reply to john.liptrot from comment #17) > > 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. Then the difference here is that I've a good CPU connected via Category 7 RJ-45 802.3 (so a fast LAN), but my gateway and broadband aren't quick. > 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. I have other people who need to use the network. For me, that's very important. I don't care if I use all of my CPU (which I definitely shan't when doing an update anyway). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #22 from Ellie --- (As a minor side note though, Steam for example which downloads 100GiB+ games also only ever used sequential downloads last time I used it. It's one of the most stable downloaders ever and I don't see people commonly complain about it being too slow. So I think parallel downloads often make less of a difference than people might think.) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #21 from Ellie --- I think the common solution for this is an option to specify the max downloads, and to perhaps not set it very high as a default, e.g. 1-2. Then those with fast connections who are annoyed by how long it takes can simply go change the setting. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #14 from Ellie --- "flatpak update" does everything sequentially, I've been using that for the last few months for that reason. Regarding what happens in KDE Discover, I've ever only seen it do parallel downloads for the flatpak updates, I saw this both on SteamOS and on multiple postmarketOS installs. My experience back then was, if you click the available flatpak update entries one by one it kind of works, if you click them all via "Update all" then usually all of them quickly fail (it doesn't seem to retry much, although I guess that could be a blessing for other applications trying to use the internet). However, I haven't checked a very recent KDE Discover version. Regarding the wifi failure, I mean isn't really a discover-specific thing, that just happens with any software if you do too many downloads at once. If I download 3+ things in the web browser at the same time, this happens too. On any machine too, really, it just depends on whether the hotspot is sufficiently slow. I imagine with an old dial up modem you would see the same problem. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #23 from Roke Julian Lockhart Beedell <[email protected]> --- (In reply to Ellie from comment #22) > Steam, for example, which downloads 100 GiB + > games, also only ever used sequential downloads last time I used it. It's one > of the most stable downloaders ever, and I don't see people commonly complain > about it being too slow. So I think parallel downloads often make less of a > difference than people might think. Most of its games are too large for parallel downloads to be of use, and I know that I pre-download (and keep updated) all of my games so that my brother can seed them over Ethernet from me. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #26 from Ellie --- It might have changed behavior since I last tried. The best way to avoid problems is to have both a switch to disable parallel connections and another to limit the download speed inside the app. However, at least in my experience on multiple different devices, just avoiding more than one connection usually already helps a lot. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
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.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #16 from Roke Julian Lockhart Beedell <[email protected]> --- (In reply to john.liptrot from comment #15) > Maybe parallel downloads in Discover are more trouble than they're worth? > Especially for slower devices and/or slower network connections. For devices on decently slow, but not massively slow, networks, couldn't parallel downloads increase performance, though? 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. 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. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 [email protected] changed: What|Removed |Added CC||[email protected] Resolution|--- |WAITINGFORINFO Status|CONFIRMED |NEEDSINFO --- Comment #7 from [email protected] --- Hello Ellie, Do you still see this issue occur? Has it at all improved since this ticket was first opened? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #11 from [email protected] --- (In reply to Ellie from comment #9) > Created attachment 185673 [details] > The "fetching updates..." screen that doesn't seem to show any progress > indicator of any kind. Can you try with the default version of Discover? Because this feature has already been added to Discover to show you which backend is refreshing behind the scenes and I have a sneaky suspicion that the theme you're using may be causing this. I assume your system has been updated since this ticket was opened, so could you please post your system specs here? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #8 from Ellie --- Created attachment 185672 --> https://bugs.kde.org/attachment.cgi?id=185672&action=edit Multiple updates show in parallel right after launch The experience was bad enough that I haven't touched it in months, but I did now, and immediately it shows me multiple parallel transfer notifications before I even touch anything, see screenshots. Afterwards, I get a long "Fetching updates..." with no total progress estimation and not even any sort of gradual progress indication of what is happening or at what speed. Afterward, I only see "System updates" which is fine, I guess nothing for flatpak that would allow me to test, but already when I click "Update all", I am faced with another lack of any sort of progress bar or progress update. There is no "Details" button, not even some sort of spinner, I can just press "Cancel" which leads to no visible UI reaction of any kind. While I'm typing this, it has been stuck showing the "Cancel" button with no information at all about what it is doing. So I can't tell you if the flatpak downloads in particular are still in parallel, but in overall the situation seems as bad as ever. (Sorry if this sounds frustrated on my end, I acknowledge this is likely hard to get right.) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #13 from [email protected] --- (In reply to Ellie from comment #12) > Oops, so perhaps I broke it then? Sorry if that's the case! > > Here are my system specs: Raspberry Pi 5 with NVMe SSD and external HDMI > screen, postmarketOS Edge based on Alpine Edge (basically the very latest > development packages of Alpine), Kernel 6.12.50-0-rpi, KDE Plasma 6.4.5, KDE > Frameworks 6.18.0, Qt 6.9.3. Is there something else of use that I could > provide? Thanks for the info Ellie. When you start an update, can you check system monitor for network/CPU/RAM usage? Does the WI-FI slow down for any other connected devices, or just this device running KDE Plasma? If it's just this device, is it the whole OS? Just Discover? etc etc Have you been able to reproduce this on any other system? Any errors/logs/warnings? Can you update via the command line? Does it produce the same results, or does this only happen with Discover? Does this only happen with flatpaks? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #24 from [email protected] --- > For me, the time it takes to download is what matters. None of my family > mind if their videos cut out for three minutes, but they do care if they > buffer for 10. I've a strong LAN, but poor internet connectivity, due to the > rural location of my residence. This appears to be the opposite of Ellie's > case. ...I don't understand? I'm confused by your wording. When you start parallel downloads, videos are "cutting out for three minutes", correct? And when you start one sequential download, it makes everybody else's videos "buffer for 10 minutes", correct? Then this is not the *opposite* issue to Ellie, it's the *exact same* issue. This is a literal description of parallel downloads saturating the internet connection. Ellie is encountering an issue with KDE software that is preventing her from using Discover for downloads entirely because it breaks the WI-FI/internet. This is directly actionable by KDE developers. What you are describing is the same bug as Ellie, but are also trying to justify its existence by claiming it is the lesser of two evils. If downloads in Discover break the LAN/WAN - That's a bug. Relevant links*** https://github.com/flatpak/flatpak/issues/5162 https://github.com/flatpak/flatpak/issues/5231 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #10 from Ellie --- Created attachment 185674 --> https://bugs.kde.org/attachment.cgi?id=185674&action=edit The "System Updates" listing being stuck while showing a "Cancel" button and no progress indicator, even after pressing said button. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #19 from [email protected] --- > I have other people who need to use the network. For me, that's very > important. I don't care if I use all of my CPU (which I definitely shan't > when doing an update anyway). You previously commented; >couldn't parallel downloads increase performance, though? 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. This is true, for *as long as* the network does not drop out when the package download begins. And in Ellie's case, that is exactly what happens. Parallel downloads multiply the number of TCP sockets used, that is how they achieve additional throughput. But if the network can't handle it, you run into problems. Why is it a problem for you if parallel downloads are swapped for sequential? You made the argument that there are other people using your network, so you need parallel updates to get the update out of the way quicker so the network can return to a stable state. Sequential downloads taking 10 minutes would not clog the network half as much as parallel downloads taking 3 minutes. In Ellie's case, Discover does not work. That is a problem. Ellie has confirmed that 'flatpak update' works fine because it is sequential. She's also confirmed that downloading multiple items at once in firefox also causes this. In your case, Discover works. If swapping to sequential updates fixes this issue for Ellie entirely, but ever so slightly inconveniences you, then I'm not necessarily convinced that the pros of parallel downloads outweigh the cons. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #25 from Roke Julian Lockhart Beedell <[email protected]> --- Saturating the connection in order to download the packages I want it to download indeed isn't a bug for me. To demonstrate, despite Ellie providing it as an example of what does it right, Steam does the same for me (actually, it's much worse than Discover). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #20 from Roke Julian Lockhart Beedell <[email protected]> --- (In reply to john.liptrot from comment #19) > Why is it a problem for you if parallel downloads are swapped for > sequential? You made the argument that there are other people using your > network, so you need parallel updates to get the update out of the way > quicker so the network can return to a stable state. Sequential downloads > taking 10 minutes would not clog the network half as much as parallel > downloads taking 3 minutes. For me, the time it takes to download is what matters. None of my family mind if their videos cut out for three minutes, but they do care if they buffer for 10. I've a strong LAN, but poor internet connectivity, due to the rural location of my residence. This appears to be the opposite of Ellie's case. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 [email protected] changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #15 from [email protected] --- Just a thought, if flatpak in the command line does not use parallel downloads and presents no problems, maybe it isn't worthwhile having them enabled in Discover. In Ellie's case, it clogs the WI-FI and breaks things. For somebody with super-fast gigabit internet & a top of the range PC, moving from parallel to sequential downloads arguably won't reduce the experience of the user by a noticeable amount anyway. Maybe parallel downloads in Discover are more trouble than they're worth? Especially for slower devices and/or slower network connections. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #12 from Ellie --- Oops, so perhaps I broke it then? Sorry if that's the case! Here are my system specs: Raspberry Pi 5 with NVMe SSD and external HDMI screen, postmarketOS Edge based on Alpine Edge (basically the very latest development packages of Alpine), Kernel 6.12.50-0-rpi, KDE Plasma 6.4.5, KDE Frameworks 6.18.0, Qt 6.9.3. Is there something else of use that I could provide? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 Roke Julian Lockhart Beedell <[email protected]> changed: What|Removed |Added CC||4wy78uwh@rokejulianlockhart ||.addy.io -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 --- Comment #6 from Nate Graham --- It would appear there things we can do on our side to make this better, yeah. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474135] Parallel Flatpak downloads can saturate a slow network and render it unusable
https://bugs.kde.org/show_bug.cgi?id=474135 Nate Graham changed: What|Removed |Added Summary|Parallel Flatpak downloads |Parallel Flatpak downloads |can saturate a slow etwork |can saturate a slow network |and render it unusable |and render it unusable -- You are receiving this mail because: You are watching all bug changes.
