Hardware revitialisation

Its been about 6 months since the last post but that doesn't mean I haven't been crunching. I've decided to update all the crunchers. I have two standard builds for x86_64 machines, one for CPU compute and the other for GPU compute, but also able to do CPU work if needed. The CPU compute machine were originally using a Ryzen 3900X but had been upgraded to Ryzen 5900X.

 

CPU compute

Motherboard:  ASUS B850-Plus Wifi
CPU:               Ryzen 7900
Memory:         96GB (2 x 48GB) DDR5-5200 MHz
Cooler:            Noctua NH-U9S
SSD:                Crucial P510 (DRAM-less) 2TB 

I opted for 96GB of memory, however one machine locked up so I have put a 64GB kit in temporarily while I return the memory kit. It would boot with a single stick of 48GB memory but as soon as the 2nd stick was added it refused to boot.

 

GPU compute

Motherboard:  ASUS B850-Plus Wifi
CPU:               Ryzen 7600
Memory:         32GB (2 x 16GB) DDR5-5200 MHz
Cooler:            Noctua NH-U9S
SSD:               Crucial P510 (DRAM-less) 1TB 

I'm reusing the RTX 3060Ti GPU for the time being. The next step up for the GPU looks like an RTX 5070 but I really don't like the 12VHPWR power connector that Nvidia has switched to using.

 

I have one more Ryzen 3600X machine that wasn't being used and might build it as a CPU compute machine if I can find a Ryzen 7900 (non-X) CPU. All the online stores I buy from seem to be selling the X version which has a higher base clock, higher boost clock and higher wattage. I reuse the case, cables and power supplies. The most expensive parts are the memory followed by the SSD's even though they are RAM-less these days.

Another quirk that I had was the new motherboards have a 2.5G network port built in, however when I connect it to a 2.5G switch they drop their network connection. It works fine when plugged into a 1G switch using the same cable. I thought it might be drivers but I have the correct one installed. The old machines all used PCIe add-in cards so I have simply put them in the new machines. Strange thing is most of the PCIe network cards have the same Realtek chipset as the motherboard and they work fine.

Close of December 2025

Farm status
CPU Only
Running Rosetta@home work.

Nvidia GPUs
Off.

Raspberry Pis
Most running Einstein@home.

For more information on the Raspberry Pis see Marks Rpi Cluster 

 

Apart from having an overseas holiday it has been rather hot recently, with the week before Christmas hitting 42 degrees (C). With the weather cooling off for Christmas day I got some of the farm running various projects.

I recently had the old ducted air conditioning system replaced, however there was a lot of activity in the loft where the farm is located, hence the longer than usual shutdown. A large portion of the loft spaces has now been taken up by air hoses and what they refer to as an indoor unit (essentially a large metal box with 2 air hoses coming in and two going out) hanging from the ceiling. Given the lost space I had to rearrange things just to get running.

CPDN and OpenIFS woes

Farm status
CPU only
Trying to run CPDN OpenIFS work.

Nvidia GPUs
Off.

Raspberry Pis
Running Einstein@home work.

For more information on the Raspberry Pis see Marks Rpi Cluster

OpenIFS woes
As I alluded to in the blog title I have been trying to run the OpenIFS work from CPDN. These require 26GB of memory and 4 CPU cores to run. Almost all have failed. I have had one or two successful runs (they take 50+ hours). The project will only give one task per machine until its returned. The tasks send trickles as they progress. The trickles are over 7GB so one needs decent upload speed as well.

The two computers I am running these on have 64GB of memory so no issue with memory usage however CPDN have admitted they have a bug with the app freeing memory which they have been unable to track down. This has been the majority of errors.

I had one fail with a disk space error. The project give a disk space limit for each task and it exceeded that by 1.5MB so the task got cancelled, even though the machine has plenty of available disk space.

Debian trixie quirks

I've upgraded 3 of the machines in the farm so far and a few quirks I have noticed with trixie when compared with the previous version (bookworm).

1. The swap partition allocated is huge. By default it gave a 48G swap partition on a machine with 64G of memory (approx 75% of memory size).

2. tmpfs is now in memory, which is probably why they made the swap so big. You can set it back to being on disk but anything created in tmpfs will be slower. It will cleanup files in tmpfs if they are in memory. I switched the two machines with 64G of memory to use disk instead of memory as I rarely see anything in tmpfs.

3. The installation failed when I did a machine with only a 512G M.2 SSD. It ran out of disk space during the install. I had to upgrade the machine to a 1G M.2 SSD to install trixie. I was installing mate as a desktop without any additional software. If it made it through I would have removed various packages after the install, but it failed near the end of the installation without any warning so I didn't get a chance. Debian could update the installer or tasksel to check for available space.

 

Update 14 Sept 2025

I kept having issue 3 above on other machines that had a 1TB SSD's. It turned out that my caching proxy had a corrupt version of firefox-esr. I cleared the cache on that machine and did another install which forced it to download everything again. How it got a corrupt file is still a mystery but it hasn't had any issue since clearing the cache.

I've now updated all my x86-64 machines.