Cuirass Ghzminutes enhancement idea

Cuirass Ghzminutes enhancement idea

[swedebugia]

Hi

I would like to estimate how long building the rust toolchain would take 
on my 2-c 2.2 Ghz laptop.

I asked on irc and had an idea of improvement:
<rekado_> swedebugia: you can check the build duration for past builds 
on ci.guix.gnu.org
<rekado_> most of the build nodes are pretty old and weak, though 
probably still faster than a 2-core celeron.
<rekado_> (we’re currently finalising the order for a replacement of all 
but two build nodes)
<swedebugia> rekado_, wow new fast nodes :)
* bzp har avslutat (Quit: Lost terminal)
<swedebugia> Maybe we could have an additional time measurement: 
Ghzminutes. E.g. if the build took 60 minutes on a 3 Ghz machine it took 
20 Ghzminutes.
<swedebugia> The build node would have to communicate the total Ghz used 
for the build. E.g. if 2-core 3 Ghz= 2*3 Ghz= 6 Ghz.

Any thoughts about this?

-- 
Cheers Swedebugia

Re: Cuirass Ghzminutes enhancement idea

[Andreas Enge]

On Fri, Jun 21, 2019 at 05:43:54PM +0200, swedebugia wrote:
> <swedebugia> Maybe we could have an additional time measurement: Ghzminutes.
> E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes.

180 GHzmin?

Andreas

Re: Cuirass Ghzminutes enhancement idea

[swedebugia]

Hi

On 2019-06-21 18:01, Andreas Enge wrote:
> On Fri, Jun 21, 2019 at 05:43:54PM +0200, swedebugia wrote:
>> <swedebugia> Maybe we could have an additional time measurement: Ghzminutes.
>> E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes.
> 
> 180 GHzmin?

Yes, thanks for correcting me!

At 1 Ghz it would have taken 180 minutes. :)

-- 
Cheers Swedebugia

Re: Cuirass Ghzminutes enhancement idea

[ng0]

swedebugia transcribed 385 bytes:
> Hi
> 
> On 2019-06-21 18:01, Andreas Enge wrote:
> > On Fri, Jun 21, 2019 at 05:43:54PM +0200, swedebugia wrote:
> > > <swedebugia> Maybe we could have an additional time measurement: Ghzminutes.
> > > E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes.
> > 
> > 180 GHzmin?
> 
> Yes, thanks for correcting me!
> 
> At 1 Ghz it would have taken 180 minutes. :)

Seems to me as if going with the established units
would make it easier to calculate, ie maybe using
decahertz (10^1 Hz) as a base unit makes it more
convenient to scale up or down in calculation
estimations?
 
> -- 
> Cheers Swedebugia
> 

Re: Cuirass Ghzminutes enhancement idea

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Swedebugia, Guix,

I was about to answer on IRC when I saw this thread :-)

swedebugia wrote:
> <swedebugia> Maybe we could have an additional time measurement:
> Ghzminutes. E.g. if the build took 60 minutes on a 3 Ghz machine 
> it
> took 20 Ghzminutes.
> <swedebugia> The build node would have to communicate the total 
> Ghz
> used for the build. E.g. if 2-core 3 Ghz= 2*3 Ghz= 6 Ghz.

https://www.tobias.gr/marx.png

Instead (and I'm probably not the first to suggest this), store 
the time taken to build each store item in the database and spit 
out some misleading number based on that.  Prefer local build 
data; fall back to build farm (new nar field?) data if a similar 
package has never been built locally.

In both cases, make innumerable ridiculous assumptions: that 
system load isn't constantly fluctuating; that store items with 
identical names aren't completely different configurations of the 
same package; that -c and -M are remotely similar; that it's not 
this week in Belgium where CPUs are being heat-throttled by the 
weather alone; that the build isn't bound by a test suite that 
takes a day to run on spinning rust (hi ceph); …

It might even give a rough idea of build time.

Kind regards,

T G-R

PS: reminds me of 
http://linuxfromscratch.org/lfs/view/stable/chapter04/aboutsbus.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Cuirass Ghzminutes enhancement idea

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Tobias Geerinckx-Rice wrote:
> (new nar field?)

Actually, that won't work, since NAR URLs are hash-based and we're 
hardly interested in packages that do have substitutes available.

One'd have to grow another /api/<name>/build-times wart or 
something.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]