Allow setting speedFactor for local builds

[timokau]

As previously discussed in https://github.com/NixOS/nix/issues/2012#issuecomment-383506460, I think it would be useful to be able to set the speedFactor for local builds. For now, the build seems to always prefer remotes (as if the local machine had an implicit speed factor of 0). My use-case of this is adding my (weaker) laptop as a remote builder for big parallel rebuilds, but still preferring local builds when enough cores are available.

[teto]

I have the exact same usecase. That would be very neat !

[jbaum98]

I also would love to have this and would be interested in implementing it, especially if someone could point me in the right direction to start.

[Ericson2314]

The issue with the remote builders are all scheduled through the build hook, which doesn't see local builds. This might be hard to untangle.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[glittershark]

this is still important to me

[stale[bot]]

I marked this as stale due to inactivity. → More info

[3541]

This is still relevant.

[MatthewCroughan]

I ran into this today. I think the current behavior is incorrect. The remote builder should only be preferred if the maxJobs of the local machine have been exhausted. But instead, builds happen almost exclusively on the remote. Weak machines can always benefit from adding a stronger remote builder, but a strong machine cannot benefit by adding a weaker remote builder to add more jobs. My use case is that I want to increase the amount of max jobs available to be performed, rather than always performing builds on the remote.

[adamcstephens]

I ran into this myself. I have a second, weaker, machine that I figured I'd send extra builds to. Unfortunately, adding a remote builder sends all the builds to that machine first which slows everything down.

[b2ag]

The issue with the remote builders are all scheduled through the build hook, which doesn't see local builds. This might be hard to untangle.

If that's the problem, the solution should be straight forward. Just configure the local machine like a remote builder and add it to the list. I have to wait for some bigger jobs to confirm it's really working like that. But nix build didn't complain so far.

Edit: Seems like it's not working as expected. Just hangs if I try with only the local machine as a remote builder.

[toastal]

Relatedly would be a fundamental understanding of network latency and data cap such as --prefer-build time vs. --prefer-build data that wouldn’t wreck a tethered mobile data setup with very high latency to build remote but also the cost to a data plan of shipping all the files to build & then shipping build artifacts back (filesets help on the input, but too many aren’t using them unfortunately). Many times it would be cheaper to build locally, but even when on the same network at home the latency of small files round-tripping the build server is slower than building on the local machine.

If Nix understood build times, network, & performance of all machines for scheduling, I would convert all my existing machines—even possibly my router (would have tears of joy for a practical Nix phone)—to Nix, letting my ‘cluster’ distribute builds in a smart manner instead of the present simplistic, naïve way. Doing this now would often schedule the most expensive build on that ARM router, & nonetheless seems to always prefer the remote device. At a minimum, I like the OPs suggestion of letting users manually set this if Nix scheduler isn’t going to be smarter.

[pshirshov]

Just bumped into this problem too. It's insane but for many of my cases this problem makes distributed nix builds much slower than local ones. I guess the only (dirty) workaround is to always enable SSHing into the local builder and to configure it as a remote one.