Re: Proposal: Build timers

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Tue, 23 Nov 2021 at 18:50, Julien Lepiller <julien@lepiller.eu> wrote:
> Do we even care that much about accuracy? I don't really care that the
> build takes 30 or 31 seconds, or even 1 minute, but I certainly care
> whether it takes 30s or 3h. I think this is also what SBUs give you: a
> rough estimate of which build is longer than the other. I think a
> simple proportionality relation would work well enough in most common
> cases. It might be quite off on a super computer, but who cares,
> really?

What if it takes 3h and the prediction says 2h?

Which build is longer than the other is already provided by data in the
build farm.  I agree it is hard to find and one improvement could be
that Cuirass or Build Coordinator exposes this data (I think it is not
so easy because for instance Cuirass knows derivation and package,
somehow and IIUC :-)).

Who cares to know how longer it would locally take if the substitute is
available*? ;-) Because at some point, this SBU should be computed.

Anyway, what would be the typical error?

For instance, I propose that we collectively send the timings of
packages: bash, gmsh, julia, emacs, vim; or any other 5 packages for
x86_64 architecture.  Then we can compare typical errors between
prediction and real, i.e., evaluate “accuracy“ for SBU and then decide
if it is acceptable or not. :-)



*available: which is not the case for LFS, though.


Cheers,
simon