[pacman-dev] [PATCH] Order downloads by descending max_size
arch at eckner.net
Sun Aug 22 19:57:15 UTC 2021
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 22 Aug 2021, Gavin Troy wrote:
> On Thu, Aug 12, 2021, at 06:38, Morgan Adamiec wrote:
>> In my totally untested theory this would slow things down. The ideal
>> situation is to have 1 large download running to soak up bandwidth and
>> then many small downloads running so they can all be set up and handshake.
> I expected the same, but when selecting packages randomly this way I see
> that there are typically a few very large packages that are both first
> to start and last to finish. Presumably it does a better job of soaking
> up bandwidth from the very beginning. If the upgrade list is only small
> and very-small packages then this might be more likely to run dry
> towards the end, but I wouldn't be too concerned over finding the
> perfect sort.
I think, Morgan's theory is wrong. When each package $i needs $s[$i] time
to download due to its size plus some fixed time $x due to the time needed
to establish a connection/latency/..., then the duration due to the $x
parts will not depend on the ordering at all. (well ok, in some edge case,
you may get unlucky, that all but one package finish at the same time and
then you'll need $x to establish the last connection - but this is pure
luck and cannot systematically be tracked by reordering the packages).
just my two cents.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the pacman-dev