Re: Proposal: Build timers

[Jacob Hrbek]

I think you are overcomplicating the implementation.. What I am proposing is to 
store the time value before and after the build and then log the subtraction of 
these two values per package (or even per package's phase).

For storage it can be either/both:
1. locally: Storing the value somewhere on the system and adding up to it each 
build to provide more accurate average.

**optionally** This local database can be shared across multiple systems that 
add values to it like simple listener waiting for POST requests.

- within the guix repo: Since we are already building the package we can take 
the time and then do the provided math in reverse to calculate the time:

    Build took 100 sec on system with 8 threads at 2.4 Ghz max cpu frequency:

    100 * (2.4 * 8) = 1920 (build time value per one thread at 1 Ghz)

    Building the package on system with 2 threads at 2.4 Ghz max cpu frequency:

    1920 / (2 * 2.4) = 400

    We can then assume that the build will take 1920/400=4.8 -> 4.8 times 
longer on this system.

The math might need to be adjusted, but it seems to be sufficiently accurate 
through my testing, fwiw I see that `(max cpu frequency * cpu threads)` is an 
important component of the equasion using the analogy of a (possibly silly) 
"pokemon battle" assuming interpreting a mathematical equasion to define the 
Health Points of the package and damage per second of the CPU then simply 
substracting these two values to determine how long it will take to build alike 
package has 500 HP -> Needs a CPU that deals 100 HP to complete in 5 sec or CPU 
that deals 50 HP to finish in 10 sec.

About accuracy: I highly doubt that we need to worry about the system noise as 
that will be mitigated after enough systems submit average build time with 
their max CPU frequency and threads used.. we shouldn't really bother past that 
at the current stage and we can always add additional metadata if needed.

Either way if we decide to not implement the logging of the build time I would 
still argue that we should still consider just plain outputting of the time 
needed to complete the phase and package as I see it as a best practice for 
monitoring and assuming that it's very cheap (5~20 cpu cycles?) in terms of 
processing resources to do so.

-- Jacob "Kreyren" Hrbek

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, November 23rd, 2021 at 1:06 AM, zimoun <zimon.toutoune@gmail.com> 
wrote:

> Hi,
> 

> On Mon, 22 Nov 2021 at 22:02, Jacob Hrbek kreyren@rixotstudio.cz wrote:
> 

> > See the proposal in https://git.dotya.ml/guix.next/GUIX.next/issues/5
> 

> If I understand well your proposal, you are suggesting to attach a value
> 

> ’build time’. While I understand it could be useful for monitoring;
> 

> especially CI (Cuirass or Build Coordinator) – but it appears useless
> 

> for your use case. Where do you want to attach such value? I think it
> 

> is not affordable to add another field (or ’properties’) for all the
> 

> packages.
> 

> When discussing the Cuirass revamp, it had been mentioned to grab the
> 

> Cuirass database and then try some analytics to infer heuristics helping
> 

> for a better scheduling strategy. However, the task is not as easy as
> 

> it appears at first. Some builds are blocked by unrelated IO
> 

> operations, e.g., [1], thus it is hard to distinguish between a
> 

> regression or something unexpected in the build farms. Something useful
> 

> for monitoring, but hard to exploit for local builds, IMHO.
> 

> Other said, the “telemetry“ you are suggesting require non-trivial
> 

> filtering to gain the robust feature you expect, again IMHO.
> 

> Last, build-time depends on the environment (how the machine is
> 

> stressed), and for instance, I do not want to stop a build because on
> 

> average people are building it using X time when my machine builds it
> 

> today using X+y time (because it is CPU stressed by something else or
> 

> whatever). Well, I am doubtful that the standard error would not be too
> 

> much compared to the mean; other said, my guess is a flat Gaussian
> 

> function because of heterogeneous hardware and various levels of stress
> 

> for the same build.
> 

> To be explicit, I do not think Guix should take care of this. From my
> 

> opinion, if the build farm does not have the substitute (guix weather),
> 

> it is a bad sign the package will build locally; therefore, if resources
> 

> are limited, before building locally, I would inspect the output of
> 

> build farms (ci.guix.gnu.org and bordeaux.guix.gnu.org). Obviously, it
> 

> depends your target architecture and some are poorly supported, sadly.
> 

> 1: http://issues.guix.gnu.org/issue/51787
> 

> Cheers,
> 

> simon

publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature