Bug 151873 - anaconda install time left algorithm
anaconda install time left algorithm
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-22 23:53 EST by Jens Petersen
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-14 16:12:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The rates from the 900th package to the 1000th package of fc6 installation (5.77 KB, image/png)
2007-01-26 14:35 EST, Joel Andres Granados
no flags Details
size of the packages from 900 to 1000 of fc6 (4.32 KB, image/png)
2007-01-26 14:36 EST, Joel Andres Granados
no flags Details

  None (edit)
Description Jens Petersen 2005-03-22 23:53:15 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).

How reproducible:
every time

Additional info:
Other improvements could probably also be made to the time left algorithm
I imagine.
Comment 1 Ricky Ng-Adam 2005-03-25 18:56:14 EST
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?
Comment 2 James E. LaBarre 2005-03-29 15:12:25 EST
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.
Comment 3 Joel Andres Granados 2007-01-26 14:35:48 EST
Created attachment 146705 [details]
The rates from the 900th package to the 1000th package of fc6 installation
Comment 4 Joel Andres Granados 2007-01-26 14:36:35 EST
Created attachment 146706 [details]
size of the packages from 900 to 1000 of fc6
Comment 5 Joel Andres Granados 2007-01-26 14:39:32 EST
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).
Comment 6 Jens Petersen 2007-01-28 19:53:34 EST
Yes, showing the installed MB/total MBs sounds good to me, or maybe just
the percentage of "installed MB/total MB" would be enough?
Comment 7 Joel Andres Granados 2007-02-01 13:22:37 EST
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.
Comment 8 Chris Lumens 2007-03-14 16:12:51 EDT
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.

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