I’d like to suggest an improvement in how download bandwidth is handled when multiple packages are being downloaded simultaneously.
Currently, when more than two downloads are running, the available internet bandwidth appears to be evenly distributed among them. While this is fair in theory, it can sometimes increase overall waiting time — especially when one or more downloads are already close to completion.
Suggestion:
Instead of splitting bandwidth equally at all times, the system could dynamically prioritize downloads that are nearly complete. Once a download finishes, its allocated bandwidth could then be redistributed to the remaining downloads.
Why this might help:
Reduces overall perceived waiting time
Finishes smaller/near-complete downloads faster
Frees up system resources sooner
Improves user experience, especially on slower connections
This kind of adaptive bandwidth allocation could make updates feel faster and more efficient without changing total data usage.
I’d love to hear thoughts from maintainers and the community on whether something like this would be feasible within DNF or Fedora’s download management system.
I don’t think it’s quite so simple. TCP has been carefully designed to utilize the available bandwidth and to share this bandwidth equally among several connections. The latter is a direct result of TCP’s congestion control. (Note that this happens in the kernel and across multiple userspace programs and their TCP connections.) Messing with that from userspace may actually lead to a worse experience.
Also, I am not sure what resources you are hoping to free sooner. As long as there are more files to download, finishing one will just start the download of the next one. Plus, TCP connections aren’t all that ressource intensive anyway.
And since TCP is designed to download with all the available bandwidth, your line will be occupied until the last download finishes, with the overall download time determined by the total amount of data divided by the bandwidth. Changing the order of the bits going over the line doesn’t change that or free up your connection, either.
Hi Lars,
Thank you for the detailed explanation — that makes sense regarding TCP congestion control and fairness at the kernel level.
I agree that TCP already ensures fair bandwidth sharing across connections, and I’m not suggesting modifying or interfering with TCP’s congestion control behavior.
What I was thinking about is slightly higher in the stack — at the DNF/librepo download scheduling layer rather than the transport layer.
For example, instead of running N parallel downloads with equal concurrency at all times, DNF could potentially:
Dynamically reduce parallelism when a download is near completion
Temporarily serialize small or near-complete payloads
Use a size-aware queue ordering strategy before initiating connections
This would not attempt to override TCP fairness, but rather influence which downloads are active concurrently and in what order they are started.
You’re absolutely right that total download time is fundamentally bounded by total data size divided by available bandwidth. However, from a user-perceived responsiveness standpoint, finishing smaller or nearly completed RPMs earlier could:
Allow earlier metadata validation
Enable faster dependency resolution for subsequent steps
Improve perceived progress feedback
Potentially reduce memory/file descriptor usage during high parallelism
So the idea isn’t to “change how TCP shares bandwidth,” but rather to explore whether adaptive concurrency or size-aware scheduling at the application level could improve perceived responsiveness without harming fairness.
If this is already handled internally by librepo or considered suboptimal for other architectural reasons, I’d be interested to learn more.
Thanks again for the clarification — I appreciate the insight.
I solve it with a config entry in /etc/dnf/dnf.conf:
max_parallel_downloads=10
Default is 3 parallel downloads. I think this is because of users with low overall bandwidth. So that they still can use the internet beside a download. The above thing is the one of the first thing I do when installing a new Fedora version.
Thanks for pointing out the max_parallel_downloads configuration — that’s helpful.
What I’m trying to describe is slightly different from just increasing parallelism.
For example, if max_parallel_downloads=10 and the queue contains a mix of very small and large packages, such as:
10 KB
30 KB
50 KB
50 MB
100 MB
500 MB
With equal parallelism, bandwidth is effectively shared across all active downloads. In that case, even the 10–50 KB packages may take longer than necessary because they are competing with very large transfers.
From a scheduling perspective, if smaller (KB-sized) packages were completed first, they would free slots immediately. Similarly, if a large MB-sized package is already at ~95% completion, it might make sense to let it finish before starting or prioritizing new small downloads again.
So the idea is not simply “increase parallel downloads,” but rather introduce size-aware or progress-aware ordering, for example:
Prefer very small packages first (so they complete almost instantly)
Allow near-complete large packages to finish before rotating priority
Avoid mixing very small and very large payloads equally when it increases perceived wait time
This would not change total bandwidth or override TCP behavior, but could improve perceived install responsiveness, especially when users are waiting for specific small dependencies to finish before proceeding.
I’m not sure whether librepo or DNF already applies any size-based heuristics internally—if it does, I’d be interested in understanding how it currently works.
I see you are going deep I can not add some other groups which are more network specific. You would need to be able to talk with the DNF developers.
Maybe you could use additional tags while moving to the ask section with your request? Including dnf5networking tags so that users which observe this tags could give you more information.
Dnf had till lately some logical calculations before downloading (i forgot the exact expression), and told the user how much download space/time it will save.
However it got discarded because it not brought really what it was expected for.
Please do not forget, the Project Discussion section is for users which are part of this groups, to manage their daily jobs they do for Fedora. I really would propose to move it to Ask Fedora aniway and give some smart tags as mentioned above.
Thank you for the clarification and the guidance
That makes sense — I didn’t realize the distinction between Project Discussion and Ask Fedora in that context.
I’ll move the topic to Ask Fedora and add the dnf5 and networking tags as suggested so it reaches the right audience.
I appreciate the direction — and thanks for the welcome as well!
I can not add some other groups which are more network specific. You would need to be able to talk with the DNF developers.