On Sat, Jan 6, 2024 at 3:56 AM Wols Lists <antli...@youngman.org.uk> wrote:
> 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 >
