Bug 151873
| Summary: | anaconda install time left algorithm | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> | ||||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | jgranado | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-03-14 20:12:51 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jens Petersen
2005-03-23 04:53:15 UTC
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. |