Bug 469680 - preupgrade progress bar is file based
preupgrade progress bar is file based
Product: Fedora
Classification: Fedora
Component: preupgrade (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-11-03 09:06 EST by Bradley
Modified: 2014-01-21 18:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-26 01:13:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
graph showing file-based progress vs size-based progress (5.36 KB, image/png)
2008-11-06 20:42 EST, Bradley
no flags Details
Random order comparision (5.49 KB, image/png)
2008-11-06 20:50 EST, Bradley
no flags Details

  None (edit)
Description Bradley 2008-11-03 09:06:11 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):


How reproducible:


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
Comment 1 James Antill 2008-11-03 09:46:06 EST
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.
Comment 2 Bradley 2008-11-06 20:41:27 EST
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
Comment 3 Bradley 2008-11-06 20:42:42 EST
Created attachment 322806 [details]
graph showing file-based progress vs size-based progress
Comment 4 Bradley 2008-11-06 20:50:39 EST
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.
Comment 5 James Antill 2008-11-06 23:40:48 EST
> 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.
Comment 6 Bradley 2008-11-06 23:48:37 EST
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.
Comment 7 Will Woods 2008-11-07 00:32:21 EST
Changing the progress bar in the preupgrade GUI is actually pretty easy - I'll put it on the TODO for 1.0.
Comment 8 Fedora Update System 2008-11-21 18:49:03 EST
preupgrade-1.0.0-1.fc10 has been submitted as an update for Fedora 10.
Comment 9 Bug Zapper 2008-11-25 23:41:21 EST
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:
Comment 10 Fedora Update System 2008-11-26 01:12:45 EST
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.
Comment 11 Fedora Update System 2008-11-26 01:13:33 EST
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.
Comment 12 Fedora Update System 2008-11-26 01:22:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.