Comment 15 for bug 438870

You're probably right that downloading for more than one transaction at a time wouldn't be worth it. (It might save time if the downloads were from different servers, because some of the latency might be at the server's end rather than the client's. But in our case they will mostly be from the same server.) So let's concentrate on downloading for only one transaction at a time.

How much time that would save would depend mainly on four things.

First, on how what proportion of the average installation time is taken up by the download, and in particular, how close that average is to 50%. (The further away it is from 50%, in *either* direction, the more often there will be slack where only one task is in progress rather than two.)

Second, on how much variation there is in that average proportion. (Even if the average is exactly 50%, if it varies a lot, there will still be lots of slack.)

Third, on the length of the average queue: how often there's an X+1 at all, and an X+2 to take up any slack from the X+1 download finishing before X finishes, and an X+3 etc.

And fourth, how much the process of downloading X+1, and writing that downloaded file to disk, slows down the process of installing X. (Maybe this is negligible.)

As far as I know, we don't have data on any of these at the moment. I expect it would be fairly easy to write a script to measure the first two at least: choose a random package, time its download, time its installation, uninstall, repeat. And measuring those first two would be useful by itself, because it would help us make the existing progress bar smoother. <https://wiki.ubuntu.com/SoftwareCenter/SmoothProgress>

As for presenting progress of downloading packages that you thought would be downloaded already, a basic way to handle that would be: estimate/measure how often it happens, estimate/measure what proportion of the total time it takes when it does happen, multiply those two together, and allocate the resulting proportion of the total progress bar to it.