Hi,
On Thu, 25 Nov 2021 at 04:03, Jacob Hrbek wrote:
> My theory is designed with tolerance of <5 min with max tolerance of
> =10 min with methods that I am confident will get us within <30 sec
> assuming sufficient amount of data to construct the variables.
Please back this claims with concre
Am Donnerstag, den 25.11.2021, 04:03 + schrieb Jacob Hrbek:
> Make it clear it's an estimate, or maybe even abstract away the time
> units so that there is no expectation of any particular time. --
> Vagrant
>
> My theory is designed with tolerance of <5 min with max tolerance of
> =10 min wit
Make it clear it's an estimate, or maybe even abstract away the time units so
that there is no expectation of any particular time. -- Vagrant
My theory is designed with tolerance of <5 min with max tolerance of =10 min
with methods that I am confident will get us within <30 sec assuming sufficie
> The “pokémon-battle” model is a simple linear model
(cross-multiplication); using Jacob’s “notation” -- zimoun
It's not designed to be linear as the HP variable could be adjusted in real
time e.g. recalculating it every X amount of time as needed which can include
calculations for noise that i
Hi Vagrant,
On Wed, 24 Nov 2021 at 12:23, Vagrant Cascadian wrote:
> On 2021-11-24, zimoun wrote:
>> What if it takes 3h and the prediction says 2h?
>
> Those sound about "the same" for any kind of reasonable expectation...
Ah, we are not speaking about the same thing thus. :-)
> I would gues
On 2021-11-24, zimoun wrote:
> On Tue, 23 Nov 2021 at 18:50, Julien Lepiller 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 y
Hi,
On Tue, 23 Nov 2021 at 14:39, Jacob Hrbek wrote:
>> This approximation would not even be accurate enough for the same
>> machine. For instance, the test suite of the julia package runs
>> mainly sequential using one thread...
>
> I am aware of this scenario and I adapted the equasion for i
Hi,
On Tue, 23 Nov 2021 at 18:50, Julien Lepiller 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 whi
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 proportional
Skimming through the research that lily provided our builds are reproducible so
the changes in cpu cycles requirements should be same with any post-build
implementation disabled, but i recognize that different CPUs might use
different configuration that influences the calculation and it will be
> Your Pokémon analogy is extremely flawed. The same CPU at a different
> clockrate does not perform the same task in the same amount of cycles [1, 2].
> -- lily
The theory is that the measurements could be taken after X amount of time to
adjust the DPS that the CPU does to the package to get
Am Montag, den 22.11.2021, 22:02 + schrieb Jacob Hrbek:
> See the proposal in https://git.dotya.ml/guix.next/GUIX.next/issues/5
>
> -- Jacob "Kreyren" Hrbek
>
> Sent with ProtonMail Secure Email.
Your Pokémon analogy is extremely flawed. The same CPU at a different
clockrate does not perform
Hi,
On Tue, 23 Nov 2021 at 07:05, Julien Lepiller wrote:
> LFS has a notion of a Standard Build Unit (SBU), that is the build
> time of a particular package on your machine. Each package build time
> is estimated in SBU. However, they do not take threads into account,
> because the relation is n
> Are you assuming here that the two machines are the same? Or are they
> different?
I am assuming that the two machines are the same with the exception of cpu
frequency and threads that are used as a variable to assume the build time from
known value.
> This approximation would not even be a
Le 23 novembre 2021 01:21:06 GMT-05:00, Jacob Hrbek a
écrit :
>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
Hi,
On Tue, 23 Nov 2021 at 06:21, Jacob Hrbek wrote:
> 1. locally: Storing the value somewhere on the system and adding up to
> it each build to provide more accurate average.
Timing is already stored, see “guix build --log-file”. Give a look at
’/var/log/guix/drvs’. For instance,
--8<--
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 o
Hi,
On Mon, 22 Nov 2021 at 22:02, Jacob Hrbek 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 Bu
See the proposal in https://git.dotya.ml/guix.next/GUIX.next/issues/5
-- Jacob "Kreyren" Hrbek
Sent with ProtonMail Secure Email.
publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
19 matches
Mail list logo
