Red Hat Bugzilla – Bug 151873
anaconda install time left algorithm
Last modified: 2007-11-30 17:11:02 EST
Description of problem:
When doing a remote install and there is a package missing for example,
anaconda waits for the user to fix the issue or reboot. After adding
the missing package and continuing the install: the time left estimate
is completely wrong (eg after leaving the installer waiting over night).
Other improvements could probably also be made to the time left algorithm
In one recent PXE boot / network install for Fedora Test 4 Test 1, the initial
install time estimate given was 28 minutes versus 64 minutes actual time (as
indicated when switching to the console). Is it a bug in the time remaining
algorithm or the algorithm not taking into account the time to transfer the data
or a problem making this install specifically slow?
To answer your question, this is not a problem specific to this test build.
Anaconda's estimation of time to completion has been way off for as long as I
remember (at least as far back as RH 6.x). General rule I've followed is if it
starts at 4hours, then drops to 1.5 hours, then to 30 min, it will eventually
creep back up to 1.5 hours by the time it's done. I've learned to anticipate
this by now, and usually figure the real time will be around the second value.
How much that helps if someone wants to troubleshoot it I don't know.
Created attachment 146705 [details]
The rates from the 900th package to the 1000th package of fc6 installation
Created attachment 146706 [details]
size of the packages from 900 to 1000 of fc6
After doing an analysis on the velocity of installation of each package I found
that the rate of installation varies considerably from package to package (see
attached figures 'y axis -> Kb' 'x axis -> package') this means that the
information taken from any part of the installation will not be relative to
other parts. This is the reason for the misscalculations. Moreover when
installation is done from the network, where traffic changes the overall
intallation behavior, the algorithm may misscalculate even further. To the best
of my knowledge I dont see an easy way to better the calculations and would
consider just telling the user the amount of Mb the anaconda has installed
compared to the amount of total Mb. ( #ofCompleted Mb OUT OF #total Mb) instead
of the time estimate (because its inacurate).
Yes, showing the installed MB/total MBs sounds good to me, or maybe just
the percentage of "installed MB/total MB" would be enough?
I have tried some other Euristics:
1. An average that accumulates as the installation moves forward (It gave more
or less the same results as the current algorithm)
2. I saved previous install times for each package and put them on a structure
in the progress_gui.py file. Unfortunately the same packages have different
behaviors when the installation changes, So no relation between current
installation time and past installation time could be visualized. The
predictions where completely wack.
The percentage is a good idea but I think the time prediction algorithm will
stay for now.
Due to issues with getting the time right, we're no longer giving a time.
Instead, we're providing a count of packages installed out of total packages to
be installed. This still provides some sort of progress information without the
problems inherent in giving a time.