Re: Proposal: Build timers

[Jacob Hrbek <kreyren@rixotstudio.cz>]

[-- Attachment #1.1: Type: text/plain, Size: 4914 bytes --]

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

[-- Attachment #1.2: publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc --]
[-- Type: application/pgp-keys, Size: 737 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]