Red Hat Bugzilla – Bug 469680
preupgrade progress bar is file based
Last modified: 2014-01-21 18:06:46 EST
Description of problem: Preupgrade's progress bar is based on the number of files to download rather than their size. The problem is that yum downloads files by size order (smallest to largest), so the status appears to move very very quickly to start with and then take longer and longer as the download progresses. Version-Release number of selected component (if applicable): preupgrade-0.9.8-2.fc9.noarch yum-3.2.19-3.fc9.noarch How reproducible: Always Steps to Reproduce: 1. Upgrade F9 to rawhide using preupgrade Actual results: After starting to download packages, the progress bar moves very quickly to start with, then slows down Expected results: Progress bar process should accurately reflect amount of data to download Additional info: yum used to download rpms randomly so this behaviour used to average out; yum started sorting downloads in one of the F9 updates
preupgrade uses the same UI as yum when downloading packages, so we have: current package, total pacakge, package name, total progress percentage, current progress percentage, current progress bar, download speed, current size, time ...while it's true that it can download 500-600 packages before the current progress is on the screen for long (which includes the total progress percentage), this wouldn't change by making the progress bar for the total amount of data to be downloaded. Also given that on a test I'm at 600/1902 and am still at a total progress of 0% ... I could see how making the progressbar be the total progress would be annoying/confusing in that it would change so slowly.
Maybe it doesn't make much different if the mirror is on a local LAN but it does if its not. I'll attach a graph that I produced by looking at the ctime of the preupgrade rpms (I haven't actually done the upgrade because something came up, although all the files are downloaded) x-axis is time in seconds, with 0 being the time that the first package would have finished downloading. y-axis is fraction complete. When the progress meter is file-based, it ends up at 80% when the download is only 30% completed, but the size-based one is roughly linear (its not quite, presumably due to the ~50ms latency combined with the very small files that it starts off with It is the same way that yum manages things, but: - with yum's line-per-package UI thats really the only way to do it. - Its clear that thats what its doing. - I don't think that yum's behaviour is ideal, but it doesn't tend to matter, since yum doesn't tend to download ~1000 (out of 1281) packages under 1M (including 400 packages under 100K) and end up with 2 packages over 100M
Created attachment 322806 [details] graph showing file-based progress vs size-based progress
Created attachment 322808 [details] Random order comparision And for comparison, heres what the two methods look like if the files were downloaded manually. Previous versions weren't actually random, but it'll do as an approximation.
> When the progress meter is file-based, it ends up at 80% when the download is > only 30% completed, but the size-based one is roughly linear I have no idea what this means. What do you mean by "progress meter"? As I said in comment #1, there are a number of stats. that are produced. One of which is the "total progress percentage" which is the second thing in brackets. This is based on size, not number of files, and so goes up "linearly". The "progress bar" which looks a bit like this: [=== ] ... is per. file (based on the file size), which seems the most useful to me given that we only have space for one.
This is a bug report for preupgrade, not for yum - http://fedoraproject.org/wiki/Image:Features_PreUpgrade_mizmo-mocks.1.png (second from the bottom) is the bit I'm talking about. Looks slightly different in the updates-testing preupgrade, but not enough to be relevent.
Changing the progress bar in the preupgrade GUI is actually pretty easy - I'll put it on the TODO for 1.0.
preupgrade-1.0.0-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/preupgrade-1.0.0-1.fc10
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
preupgrade-1.0.0-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
preupgrade-1.0.0-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
preupgrade-1.0.0-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.