| 1 |
On Sun, Jul 31, 2016 at 6:47 AM, Peter Humphrey <peter@××××××××××××.uk> |
| 2 |
wrote: |
| 3 |
|
| 4 |
> |
| 5 |
> How is it possible for genlop's reported ETA to increase while its time |
| 6 |
> spent so far also increases? Could the concurrent gnutls merging have |
| 7 |
> affected it? Surely not. |
| 8 |
|
| 9 |
|
| 10 |
I've noticed the same oddity recently while building a couple of new amd64 |
| 11 |
boxes. Unfortunately, I can't document my observations |
| 12 |
with precise numbers, but I have noticed it on multiple occasions when |
| 13 |
simultaneously emerging, say, two packages that each |
| 14 |
take hours to build. As an example, If the estimate for the remaining time |
| 15 |
was another 1/2-1 hr while the 2d build was sharing system |
| 16 |
resources with the 1st, I've seen the 2d build estimate jump to 1-2 hr when |
| 17 |
having exclusive access to system resources after the 1st |
| 18 |
finishes. It's almost as if somewhere in the code there's logic that |
| 19 |
estimates time remaining as proportional to available system |
| 20 |
resources available instead of inversely proportional. |
| 21 |
|
| 22 |
This isn't a subtle anomaly, in my opinion. I've used genlop in this way |
| 23 |
to monitor build times for ages and I've never seen it behave |
| 24 |
this way before. And I haven't changed my build options by fooling around |
| 25 |
with -jN or by trying to do other things on the system while |
| 26 |
emerging. New behavior for genlop, or a 32/64 bit thing? (I've recently |
| 27 |
gone 64 bit and that's where I see the discrepancy.) Glad |
| 28 |
to see that someone else has experienced the same thing, and I'm not going |
| 29 |
crazy (although some might argue this is hardly proof...) |
| 30 |
|
| 31 |
John Blinka |
Archives