If you want to work on it one important question is "How accurate do
you want it?" Another important question is "How much time do I want
to divert from the installs to the estimates?"
I suspect you could get fairly accurate if you add 50% to the install
time to scan each of the install files and base your estimates on what
you find. The ideal, however, is a very unobtrusive estimator that eats
maybe 1% to 5% of the total install time.
{^_-}
From: "Tino Meinen" <a.t.meinen@xxxxxxxxx>
> Hmm, interesting, jdow.
>
> So, guestimating total time is a tricky problem, involving lots of
> different things, and depending on what you'r guestimating (total
> download time of a file, total install time for a set of packages, total
> compile time of a program, etc)
>
> Maybe this could be a fun project to look into for the not so serious
> developers not working on serious projects :-)
> It might even be me, some time in the future!
> (I'm now working out how long it would take me to solve this problem)
>
> Tino
>
> Op za 19-07-2003, om 01:47 schreef jdow:
> > I've looked at this from time to time. Each time I look I bounce.
> > There are simply too many unknowns to get a good time estimate. You
> > can get a "percent of the total number of packages installed." Beyond
> > that you need to develop heuristics for the disk speed, the likely
> > time to install an rpm of a given size, and so forth. Disk speed is
> > fairly easy to nail down. Actual place a file on disk time may vary
> > somewhat with the number of files in the destination location. The
> > time to place an RPM on the disk is highly variable. It varies by
> > the amount of data that needs to be transferred to disk, the number
> > of files, and the amount of post copy prep that needs to be done.
> > These may vary depending on what other packages are installed. The
> > "Microsoft Minute" phenomenon is something that it's quite difficult
> > to overcome. (Although Microsoft seems to carry it to an extreme of
> > time estimating silliness. What would anyone expect? They cannot
> > improve it because too many users would have coronaries if Microsoft
> > actually made it accurate. The users would think the world had come
> > to an end. {^_-})
> >
> > So it's probably easiest to go with percentage of the number of
> > files to be installed and a very rude and crude time estimate.
> > That way there's more time for the serious developers to work on
> > serious problems. (Er like, let's get a GOOD 2.4 someday.)
> >
> > {^_-}
>
> > ----- Original Message -----
> > From: "Tino Meinen" <a.t.meinen@xxxxxxxxx>
>
>
> > > But I see these kind of inaccurate guesses in other places as well.
> > > Making an estimate for a progressbar or 'total-time', is a very common
> > > thing to do for a program(mer), so I wonder if there is a generic
> > > library available somewhere where these type of things are handled in
a
> > > more scientific manner.
> > >
> > > Tino Meinen
> > >
> > > > When installing Shrike (and all prior versions, for that matter),
the
> > > > estimated total time is grossly inaccurate. On a 1GHz P-III/M laptop
> > with
>
>
>
> --
> Shrike-list mailing list
> Shrike-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/shrike-list
--
Shrike-list mailing list
Shrike-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/shrike-list
