Ducking and diving
Like most IT professionals, one usually aspires to have cutting-edge kit where financially feasible. In my case, I built a catch-all desktop rig last year for software development, virtualisation, and gaming. Previously, I usually had a gaming rig and a separate server box for running labs and so forth.
My current rig is as follows:
- Ryzen 9 9950x3d – £699.98 Inc VAT
- Corsair Vengeance Black 96GB 5600MHz DDR5 Memory Kit – £229.99 Inc VAT
- ASRock AMD X870E Nova WiFi 7 – £367.99 Inc VAT
- And so on
- And so forth
Why have I put the prices I paid for these components? Because if I want to add another 2 sticks of RAM to the rig, it will now cost this:
A mere £810 increase. So I have decided to stop maxing the memory for now. This is disappointing, as some of the projects I am working on really need dozens of VMs to achieve adequate testing coverage before serious testing on larger hardware or in the cloud.
Rolling back to the DDR3 era
Introducing my trusty old server, built in 2014 and upgraded over the years. It has been so long since I used it that I have forgotten most of the specifications, especially surrounding the disks.
(My cable management is a disgrace)
I was absolutely shocked that the case was NOT as dusty and filthy as I imagined. It has been under the desk on the carpet for 11 years, so I expect things to be living in there.
After opening the case and looking at my purchase history. Here is what I could easily identify
- ASUS Z9PA-D8 – This board is novel as it is the standard ATX form factor despite being dual socket
- Dual E5 2697 V2 CPUs – An absolute monster in its day, 12 big cores with hyper-threading (3.50GHz boost clock)
- HP 256GB (32GB x8) PC3L-10600L DDR3L-1333 – 256GB DDR3 ECC old school memory. Motherboard is maxed.
- ASUS PIKE 2008 RAID Card
- 4 x WD 1TB WD1003FBYZ RE SATA – I remember this RAID array was a volume to hold non-VM data
- RTX 2060 Super – Old gaming card slotted in about 5 years ago to replace a dead GPU
- Silverstone ET650 PSU – Bog standard PSU to replace a dead Corsair PSU years ago
I noticed I had two PCIE cards slotted in with NVME SSDs:
I pulled them:
Looks like bog-standard NVMe SSDs. I recall that whilst latency was great, I was limited by the PCIE 3.0 lanes. In this case, I have decided to pull these permanently for now to try a cheaper storage architecture before re-visiting NVME.
In with the new (but still old)
Rather than using NVME via a cheap PCIE controller board, I decided to install a LSI 9207-8i SAS host bus adapter instead and load it up with second-hand SSDs in a JBOD config. Remember, this is a rubble box, and there is no point spending lots of money on top-tier NVMe disks that the board can’t handle. This card marries up with the PCIe 3.0 lanes on my board era wise.
In any case, for this build, I would rather have lots of storage that does the job than small amounts of fast storage that fits nothing on it. In addition, for practising performance tuning, blazing fast storage can be too fast when trying to replicate perf issues seen out in the field.
Slotted in:
For now, I connected up a single generic 1.92TB Enterprise SSD from HP and left it dangling. We want to test that the thing works before boxing it back up.
Will she start?
Time to fire her up…
We have a heartbeat (a bit warm, though).
Looks all present and correct. The date was correct at the time the server was started up!
Booting into the Windows installer from USB also works:
The Operating System
I decided to install Windows Server 2016 as this is the latest version of Windows the chipset supports. The previous operating system was a newer Linux distribution that I have decided to park for now.
Is Windows Server 2016 still viable for a home lab? Probably not long-term, as using more modern guests, such as Windows Server 2022/2025, is not supported. They do work, however.
Long term, I am likely going to use something like Proxmox VE for virtualisation. I only installed Windows Server for now to ascertain if the box works and is usable.
HammerDB Performance
I decided to do a quick performance sanity check against a small VM in Azure using different disk tiers. In this test, I ran HammerDB against both a small 4 vCPU/16GB VM on the Rubble Box and compared to an Azure VM using different storage tiers.
Azure VM Specs:
Standard D4ds v5 (4 vcpus, 16 GiB memory)
Disks layout:
Premium SSD V2
- 256GB
- 128GB
- Temp disk used for Tempdb – (150GB)
All left on default 3000 IOPS:
Premium SSD
- P15 – (256GB)
- P10 – (128GB)
- Temp disk used for Tempdb – (150GB)
Standard SSD
- E15 – (256GB)
- E10 – (128GB)
- Temp disk used for Tempdb – (150GB)
Host caching was set to read-only on the disks that hosted mdfs etc.
For the VM on the Rubble Box, all disks for the VM were hosted on the single SSD I showed previously.
The goal of this test was just to test how a VM on an ancient server with a SATA SSD holds up against a simple Azure VM.
Workload
Due to the DeWitt clause, the actual Transactions Per Minute and New Orders Per Minute results will not be published; only the performance difference over baseline (the Rubble Box).
I opted to go with the following set of tests:
- 1 Virtual user – (No keying and thinking time)
- 2 Virtual users – (No keying and thinking time)
- 4 Virtual users – (No keying and thinking time)
- 6 Virtual users – (No keying and thinking time)
- 8 Virtual users – (No keying and thinking time)
For each configuration, I ran five workloads to give me statistically valid results using a 95% confidence interval. The TPCC database was built specifying 640 warehouses and was around 90GB in size. I specified 1 minute of ramp-up time with a test period of 4 minutes, with a checkpoint occurring at the end. I also built in an extra minute after each run, as I was using autopilot and wanted the servers to settle down between runs.
When not using keying and thinking time, HammerDB performs as much work as possible so SQL Server is driven as fast as it can for the given workload. The application server, both in Azure and on the Rubble Box, was a separate, 4 core VM with 16GB of RAM.
SQL Server considerations
The following version of SQL Server were tested:
- SQL Server 2025 – 17.0.4035.5
As per the HammerDB best practices guide, I picked out the following:
exec sp_configure 'show advanced options', '1' exec sp_configure 'recovery interval','32767' exec sp_configure 'max degree of parallelism','1' exec sp_configure 'lightweight pooling','1' exec sp_configure 'max worker threads', 3000
I also ensured I grew out the data and log files and set file growth to sane values.
Results
Looks like the Rubble Box VM holds up well against the Azure VMs on various storage tiers. Of course, the Azure VM is IOPS-limited both at a VM level and at the disk level (depending on tier and size). But still, I am comparing them, so this is the result.
Here are the performance gains/losses over the Rubble Box baseline:
The single-user benchmark is telling, as this potentially highlights the single-threaded performance of newer architectures in the cloud, unbounded by IO constraints.
I am pretty pleased with the performance of this single small VM on the Rubble Box. It shows that small test VMs are absolutely fine in comparison with something I would spin up in the cloud. Of course, the Rubble Box will not scale up in IO performance as disks and VMs sizes are increased, but I like what I see. I also appreciate that noisy neighbour syndrome will be a thing on this host if multiple VMs are online and large loads are running.
Summary
I am pleased with the initial resurrection of this old server. The Rubble Box was born and is now awaiting further work, including:
- Installation of more Enterprise SATA SSDs
- Ebay more than likely
- Installation of a more future-proof operating system to enable newer guest OSes.
- The server will not be on 24/7, so power consumption not likely an issue
- Power consumption will be analysed once stuffed full of disks and under appreciable load
- The Rubble Box will be run into the ground like an old car, once dead, it will be disposed of at the computer rainbow bridge (the tip)