On 06/01/2024 00:54, John Blinka wrote:
> I’ve often found that it gives one estimate when multiple packages are
> being built, then a much longer estimate for still-in-progress builds
> once some of the builds have finished.
>
> That result defies common sense. Less remaining work has to take less,
> not more (much more), time.
Common sense isn't common and, well, often doesn't make sense.
If there's a bunch of small builds skewing the "time per build" estimate
down, as they drop off the list the estimated time per build will go up,
and if the skew is serious enough it can even make the total estimated
time go up ...
I don’t follow you. What is the source of this “skew”? Why should more available processing power/less load cause builds to run more slowly? I’d really like to understand your point.
I have observed what I reported above many times, often when there are 2 builds running, a long one and a shorter one. Once the shorter one ends , the longer one’s time estimate via genlop increases , sometimes by 2x. And it doesn’t actually take 2x longer - the new estimate is just grossly wrong. Invoking skew or common sense being uncommon/wrong doesn’t change my and the original poster’s observations that genlop sometimes gives really bad time estimates. Something’s not right.
Respectfully
John