Bug 474135

Thank you for the bug report!

Please note that Plasma 5.26.1 will not be supported for much longer by KDE; supported versions are 5.27, and 5.27 or newer.

Please upgrade to the latest version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.

> your entire internet will die

Can you clarify what this means exactly? The connection goes offline for every app, or the individual downloads simply proceed so slowly that they never complete or time out?

All connections timeout but not just for KDE Discover, because it clogs the wifi too much. So the internet connection in theory is still available, but in practice it goes offline for every app.

Thanks.

My apologies, I gave the wrong github issue link for the parallel download ticket there: https://github.com/flatpak/flatpak/issues/5231

Did I understand correctly however that the parallel queuing seems to be happening on the KDE Discover side, and isn't some inherent flatpak backend feature? In that case it would make sense for me to close the flatpak issue.

It would appear there things we can do on our side to make this better, yeah.

Hello Ellie,

Do you still see this issue occur? Has it at all improved since this ticket was first opened?

Thanks!

Created attachment 185672 [details]
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.)

Created attachment 185673 [details]
The "fetching updates..." screen that doesn't seem to show any progress indicator of any kind.

Created attachment 185674 [details]
The "System Updates" listing being stuck while showing a "Cancel" button and no progress indicator, even after pressing said button.

(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?

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?

(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?

"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.

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.

(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.

> 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.

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).

> 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.

(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.

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.

(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.)

(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.

> 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

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).

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.