Bug 713460

Summary:	media-based dist-upgrade time prediction is wrong
Product:	[openSUSE] openSUSE 12.1	Reporter:	Bernhard Wiedemann <bwiedemann>
Component:	YaST2	Assignee:	Ladislav Slezák <lslezak>
Status:	RESOLVED WONTFIX	QA Contact:	Jiri Srain <jsrain>
Severity:	Minor
Priority:	P4 - Low
Version:	Factory
Target Milestone:	---
Hardware:	All
OS:	SUSE Other
Whiteboard:
Found By:	System Test	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Bernhard Wiedemann 2011-08-22 14:38:05 UTC

Media-based dist-upgrades are part of my openQA tests.
Tests use a fast local mirror and install onto a fast SSD.

You can watch such an install at
http://openqa.opensuse.org/opensuse/permanent/video/openSUSE-NET-x86_64-Build0220-11.4kde64dup.ogv around 01:37 - 01:49

The video is accelerated by factor 60, so the 12 seconds are actually 12 minutes.

Actual Results:
after 3 mins / 31% of the upgrade, the Time Remaining estimation is 00:07
after 6 mins / 57% of the upgrade, the Time Remaining estimation is 02:12

Expected Results:
estimation should be more monotonous as it is with normal installs
and should better reflect the actual time it took / will take
e.g. using above examples, simple linear extrapolation would yield better estimations for Time Remaining:
  3/0.31*(1-0.31) = 6.68
  6/0.57*(1-0.57) = 4.52

...though this can give bad results when the speed of your media or network changes a lot.

Reproducible: Always

When watching such an dist-upgrade live, I thought that estimation became so low after sequences of very small libxyz.rpm packages were installed in a short time and grew larger when bigger packages were installed.
Maybe estimation uses the number of packages where the size of packages would be a better measure of effort?

Comment 1 Ladislav Slezák 2011-08-30 11:59:21 UTC

Actually the time estimation code is already quite complex, it uses installed bytes per second for estimation (computed dynamically). This can be affected by small packages which have long running post-install scripts.

It has also some "pessimistic factor" as RPM gets slower when more packages are installed so the estimation is not linear, it contains minimal and maximum time constants, ...

The fast SSD might also cause some inaccuracy as package installation is fast but the post install scripts take relatively much time so the target time gets more accurate later.


The code is really complex and to be honest I don't dare to touch it (moreover I'm not the original author) - I guess that fixing this case would break some other case...

Anyway it is just an estimation, it cannot be perfect (because of post install scripts, possible network speed changes, DVD medium read retries, etc...)

Resolving as WONTFIX, sorry.