| 1 |
On Sunday 31 Jul 2016 10:48:33 Fernando Rodriguez wrote: |
| 2 |
> On 07/31/2016 06:47 AM, Peter Humphrey wrote: |
| 3 |
> > I've just encountered something I can't explain. Can anyone here? |
| 4 |
> > |
| 5 |
> > ~ $ genlop -c -f /mnt/rescue/var/log/emerge.log |
| 6 |
> > using logfile /mnt/rescue/var/log/emerge.log |
| 7 |
> > Currently merging 281 out of 287 |
| 8 |
> > * net-libs/gnutls-3.3.24 |
| 9 |
> > current merge time: 1 minute and 44 seconds. |
| 10 |
> > ETA: less than a minute. |
| 11 |
> > Currently merging 264 out of 287 |
| 12 |
> > |
| 13 |
> > * sys-devel/gcc-4.9.3 |
| 14 |
> > current merge time: 7 minutes and 12 seconds. |
| 15 |
> > ETA: 3 minutes and 13 seconds. |
| 16 |
> > |
| 17 |
> > $ genlop -c -f /mnt/rescue/var/log/emerge.log |
| 18 |
> > using logfile /mnt/rescue/var/log/emerge.log |
| 19 |
> > Currently merging 264 out of 287 |
| 20 |
> > * sys-devel/gcc-4.9.3 |
| 21 |
> > current merge time: 15 minutes and 19 seconds. |
| 22 |
> > ETA: 3 minutes and 41 seconds. |
| 23 |
> > |
| 24 |
> > How is it possible for genlop's reported ETA to increase while its time |
| 25 |
> > spent so far also increases? |
| 26 |
|
| 27 |
...or to change at all, for that matter. |
| 28 |
|
| 29 |
> It is an estimate (a prediction) so it's subject to change. |
| 30 |
|
| 31 |
Yes, but the estimate is derived from an average of the durations found in |
| 32 |
the log file, so it can't change until the emerge is complete. |
| 33 |
|
| 34 |
> > Could the concurrent gnutls merging have affected it? Surely not. |
| 35 |
> |
| 36 |
> Probably, I don't know if genlop takes that into account. But there's |
| 37 |
> countless factors that affect build time that it's practically impossible |
| 38 |
> to predict accurately. So it means nothing. |
| 39 |
|
| 40 |
I think that's too pessimistic. If all your emerges have -j1, the accuracy |
| 41 |
is pretty good, or it used to be in the days when I did that. The major |
| 42 |
factor affecting the durations nowadays is -j > 1, so any other packages |
| 43 |
could be emerging at the same time, thus skewing the log record. |
| 44 |
|
| 45 |
Another, even bigger log skewer is my practice, if I need an emerge -e, of |
| 46 |
doing it in two stages: -eB first, then reboot to a minimal system and -eK. |
| 47 |
That avoids things like kdelibs being different when I come to reboot the |
| 48 |
system next time and hanging up during shutdown. |
| 49 |
|
| 50 |
> Does that estimate even look reasonable to you? |
| 51 |
> gnutls compiles in a few minutes but gcc takes significantly longer for |
| 52 |
> me. |
| 53 |
|
| 54 |
No, as I said, genlop's own estimates are poor nowadays, but I can make a |
| 55 |
rough estimate myself from comparing "genlop -c" with "genlop -t <package> | |
| 56 |
grep minutes". |
| 57 |
|
| 58 |
-- |
| 59 |
Rgds |
| 60 |
Peter |
Archives