Re: [gentoo-user] genlop times was: migrating to gcc-3.4.4

[Fernando Meira]

On 8/25/05, Willie Wong <wwong@×××××××××.edu> wrote:
>
> On Thu, Aug 25, 2005 at 11:51:32AM +0000, Fernando Meira wrote:
> > I have a P4-2.4GHz laptop.
> > I forgot to say that the estimation time was made by genlop. And was
> quite
> > wrong! It took something like 11h to compile 112 packages, (though I've
> > interrupted while compiling gcc-3.3.6.. so it had to restart it anew).
> From
> > this, I don't know if I should trust genlop anymore.. or is there
> something
> > to configure so that it is more accurate?
> >
> > Just for the record, the migration to gcc-3.4.4 went just fine.. until
> now
> > at least. :)
>
> hum. Genlop looks at the past emerge times of the packages, calculates
> an average based on that.
>
> The one thing genlop can't do is figure out how long it takes to merge
> new packages. So it just skips them. That is the only way I see genlop
> being wrong by so much. (The other possibility is that you were
> running the box with a high load WHILE compiling, though I guess you
> won't be complaining if that were the case.)


That was not the case. I started emerge system just before going to bed, so 
it had all cpu for itself (considering that the remaining apps, such as X, 
and others, were not very active).
I would say that most of the emerged packages were emerged before.. but 
maybe not that much so that genlop could be accurate. Also, a new compiler 
was being used.. no idea how much can that change the performance.

To be honest, I've found the genlop time quite reliable... I've
> rebuilt my systems with --emptytree a few times in the past 6 months.
> (Once after killing PAM and LDAP, once after changing to hardened,
> once after changing from ~x86 to x86, and once after a major rehaul of
> my USE flags; these are on my desktop machine only). The 500 or so
> packages came up to be 1 day and 15 hours from genlop. The actual
> compiles never took more than 2 days, and that was while the computer
> was still in use. Once it actually finished before the estimated time.
>
> Do note that, however, genlop can only calculate its merge time based
> on past averages. So if you made major changes to your system, or if
> the codebase changed significantly upstream, genlop can be completely
> wrong. For example, looking at past emerges of glibc, I see the
> compile time goes from everything between 28 minutes to 3 hours.
> genlop tells me that if I were to remerge glibc it would take me 1
> hour and 9 minutes. But I know from experience if I were to install
> 2.3.5-r1, it will most likely only take me 40 minutes, and if I were
> to compile glibc-2.3.4.20050125-r1, it will take me about 2 hour and
> 10 minutes. Why the funky discrepancy I don't know. So I think that
> while genlop is generally rather reliable for a rough idea on how long
> I need to wait for the compile (i.e. is it worth it just sitting here
> reading a book or should I just go to bed), the numbers it give should
> be taken with a grain of salt if you don't have a large number of
> history of emerges for it to base its guesses on.
>
> W
>

Ok.. so I'll get better estimations the more times I update my system. 
Great!! That was in fact the first time I've used genlop. It's quite 
interesting to be able to predict how much something will take to emerge. 
For what you said, "is it worth it just sitting here reading a book or 
should I just go to bed", would it be possible to check an active emerge for 
the estimated time left? That would tell you what you should do... does 
genlop do that?

Cheers,
Fernando