| 11 Oct 2024 |
 Mic92 | dgrig: what is blocking you specifically? | 08:07:55 |
 dgrig | In reply to @joerg:thalheim.io
dgrig: what is blocking you specifically? I don't have a "blocker" per se from the nixos infra team. I've been experimenting locally with the security tracker and some other software that fricklerhandwerk wants deployed in an official namespace and manner. On the security tracker front I have some thing to figure out still, but for others (say Odoo if it's ok for us in the end) I want to sync with someone at some point on how we best want it deployed (i.e. does it belong on the non-critical infra, how do we want to backup the database, etc). | 08:21:11 |
| Mic92 | Sure. Do Thursday, 18:00 CEST the next week work for you? | 08:23:58 |
| Mic92 | * Sure. Does Thursday, 18:00 CEST the next week work for you? | 08:24:09 |
| dgrig | In reply to @joerg:thalheim.io
Sure. Does Thursday, 18:00 CEST the next week work for you? Yes, I've blocked all the nixos infra meetings in my calendar so I can attend them. | 08:24:39 |
 fricklerhandwerk | In reply to @joerg:thalheim.io
What is your expected update cadence? Hm, good question. That will depend on whether we get follow-up funding and how much, but say something between 1 week and 1 month | 08:25:23 |
| fricklerhandwerk | In reply to @fricklerhandwerk:matrix.org
Hm, good question. That will depend on whether we get follow-up funding and how much, but say something between 1 week and 1 month There is already automation in place to do continuous deployment to staging, and we'll re-use that for production. | 08:26:14 |
| Mic92 | What is s3 used for? | 08:29:56 |
| Mic92 | Just seems to be backup as far as I can see | 08:30:55 |
 Tristan Ross | In reply to @emilazy:matrix.org
wouldn't that run into the atomics and platform purity problems wrt the evaluator? @tomberek:matrix.org: and I were discussing this a bit last night and we're not entirely sure atomics is an actual problem. How does it affect Hydra? Wouldn't this be an issue with a C++ compiler. Hydra appears to run fine from what I've heard when running on aarch64-linux. The purity thing though, as long as the system is passed through and things are expected right, shouldn't be a concern? | 13:40:41 |
 vcunat | Tristan Ross: I believe the point was around x86 being strict around reordering of instructions while ARM is not. On language level you then need to be careful around https://en.cppreference.com/w/cpp/atomic/memory_order | 14:02:11 |
| Tristan Ross | In reply to @vcunat:matrix.org
Tristan Ross: I believe the point was around x86 being strict around reordering of instructions while ARM is not. On language level you then need to be careful around https://en.cppreference.com/w/cpp/atomic/memory_order Wouldn't this affect the nix cli itself and literally everything? | 14:08:29 |
 K900 | No | 14:08:42 |
| K900 | hydra-queue-runner is like 3k lines of C++ | 14:09:00 |
| K900 | On top of the normal Nix things | 14:09:06 |
| K900 | It's those bits I'm worried about, not Nix | 14:09:15 |
| Tristan Ross | Oh, is there a way to test the queue runner in a way to trigger it breaking because of this on aarch64? | 14:10:29 |
| K900 | Not really without just running it | 14:10:49 |
| K900 | Realistically this is not a big problem | 14:11:00 |
| K900 | It can be tested and fixed | 14:11:03 |
| K900 | Probably in a reasonable amount of time | 14:11:09 |
| K900 | It's just another thing to be aware of if migrating to aarch64 | 14:11:29 |
| K900 | And I genuinely don't see why we need to go aarch64 instead of just upgrading to a beefier and/or better cooled x86 | 14:12:13 |
| K900 | Hydra needs throughput, not latency, so it won't really care if we have many small cores or few big cores | 14:12:58 |
| Tristan Ross | I'm just thinking in cost versus performance, if we're able to get more performance at a lower cost then wouldn't that be better than spending on a beefier expensive but similar performing system? | 14:14:29 |
| K900 | Depends on how much the cost difference is | 14:14:55 |
 hexa (signing key rotation when) |
- current: AX101, 5950X (16C/32T @ 3.4 GHz Base Clock), 128 GB RAM (~106 EUR/mo)
- alternatives:
- AX162-R, Epyc 9454P (48C/96T @ 2.75 GHz Base Clock), 256 GB RAM (~241 EUR/mo)
- RX220, Altra Q80-30 (80C @ 3.0 GHz Base Clock), 256 GB RAM (~260 EUR/mo)
| 14:15:50 |
| hexa (signing key rotation when) |
- parallel compress slots (currently limited at 30, which seems reasonable in relation to the compute rhea has)
- eval memory, which we compensate with zram at 150%
- eval time, which is single-threaded and probably not fixable through hw upgrades
| 14:15:57 |
| hexa (signing key rotation when) | * bottlenecks:
- parallel compress slots (currently limited at 30, which seems reasonable in relation to the compute rhea has)
- eval memory, which we compensate with zram at 150%
- eval time, which is single-threaded and probably not fixable through hw upgrades
| 14:16:15 |
| K900 | Yeah I was going to say that Hetzner doesn't really have cheap ARM | 14:16:25 |
