AmeriBrit 20U Rack
Media / Game / Cloud

RAM — checked, and it's the good answer

Confirmed: 2× 8 GB DDR4-2666, so the box is running dual-channel. That was the one blocking question in Option B and it has resolved the right way. Full ~42 GB/s against the FX rig's ~21 GB/s, so the memory-bandwidth advantage in the comparison below is real and not conditional. Shorter GC pauses come with it.

What it costs is the upgrade path. Two slots, both full — so more memory means replacing both sticks, not adding one. That is the same trap the FX-6300 is already in with all four DDR3 slots occupied, and it is worth seeing it coming rather than discovering it with a single SODIMM in hand.

16 GB is still a step down from the FX rig's 20 GB, and that has not changed. If the current instances are allocated more than roughly 12 GB of heap between them, Option B is worse on day one — single-thread advantage does not buy back a heap ceiling. Check what the running instances are actually allocated before deciding; this is now the only open question on the RAM.

So the 2× 16 GB kit drops from mandatory to conditional. At ~$40 it takes the box to its 32 GB ceiling, and the pulled 8 GB sticks become spares — but there is no longer a channel-configuration reason to buy it. Buy it if the heap number says so, not on principle.

Performance, honestly

The gain is real but narrower than a first look suggested. Corrected against the actual platform:

The storage row may matter more than the CPU row. Option A's controller runs in IDE mode on SATA II — no NCQ, no reliable TRIM. Chunk loading and world saves are bursty random reads that stall the main tick thread while they complete. Moving to NVMe shows up as fewer TPS dips rather than a better average, and dips are what players actually feel.

3.8 GHz is a boost figure. A 35 W part in a 1 litre chassis will hold ~3.2–3.4 GHz all-core under sustained load, so the single-thread advantage holds up better than the multi-thread one.

Where Option A genuinely competes: four or more simultaneously busy instances. Six Piledriver integer cores against four Zen cores is roughly a wash on aggregate throughput — about 5.3 FX-equivalent cores on a 2200GE. It still loses on the metric players feel, because each world's tick rate is bound to a single thread.

Two rows where the FX wins outright: heap ceiling (20 GB against 16 GB until the kit lands) and sustained all-core clocks, since it has 95 W and no thermal envelope to respect.

Do it all while the case is open

The case comes apart for the drives and the RAM regardless, so do these in one session.

The fin stack is the biggest single win on a used mini — dust packs where you cannot see it — and factory paste is 2019 vintage. NVMe throttles hard with no airflow, which is what the M.2 pad is for.

Free levers, and they are AMD ones. Set the fan profile to maximum cooling; HP's defaults assume a desk, not a rack. Cap cTDP in BIOS if HP exposes it — a Minecraft server is bound by 1–3 threads and does not need sustained all-core boost. On Linux the tool is ryzenadj for STAPM/PPT limits, not intel_rapl or MSR 0x150.

Raven Ridge has no equivalent of Intel's undervolt offset interface. Power limits are the lever here; voltage offsets are not available.

Confirm AHCI rather than RAID before installing. Unlike Option A this should already be correct, but it is a two-second check against a reinstall.

Placement: not directly above the media server's rear 80 mm exhausts, and leave the U above it clear unless whatever sits there has an open bottom — stacking on a perforated top chokes it. Preferred position is at or near the network shelf: low draw beside low draw, away from the 4U.

Validation — and the go/no-go

Baseline the FX rig before you migrate anything. It is running today, and this cannot be done afterwards:

/spark tps · /spark profiler start --timeout 300

Record MSPT, not TPS. TPS pins at 20 until it doesn't; MSPT shows the actual headroom.

Then load the HP with a populated Minecraft instance for one hour, not stress-ng. A game server's thermal shape is nothing like an all-core torture test. Watch it with sensors (k10temp reports Tctl/Tdie) and watch -n1 "grep MHz /proc/cpuinfo", and watch both drives too — nvme smart-log /dev/nvme0 and smartctl -a /dev/sda. The NVMe should stay clear of its throttle point once padded; if it does not, the pad is the problem, not the workload.

Pass criteria: clocks hold ~3.2 GHz+ all-core with no sustained drop toward base. Raven Ridge Tctl throttles at 95 °C, and sustained 75–85 °C under load is normal and harmless. Temperature alone is not a failure — only clock collapse is.

If tick rate is poor at acceptable temperatures, the cause is JVM heap and GC configuration, not cooling. Do not buy hardware for a software problem.

Eight checks, all must pass. Any failure falls back to Option A with nothing lost.

If it turns out to be a 2200GE (4C/4T): four threads against the FX's six cores is acceptable for one or two instances. If you run three or more populated worlds simultaneously, benchmark before committing — that is the one configuration where Option A's core count could genuinely hold up.

Only after measurement, and in this order: swap to the 65 W thermal module (~$25–30 used) if it pairs an aluminium heatsink with a 65 W CPU; replace the fan (~$25–30) if it is audibly worn or the RPM curve looks wrong; a 40/60 mm fan on a printed bracket (~$10) as a last resort. Cutting the top and bolting on a tower cooler is not on the list — that rebuilds the 2U we just deleted.

What happens to the FX-6300

Do not rack it as a second node. It is a 95 W platform that idles high, with a SATA II controller in IDE mode — roughly $75–125 a year in electricity at 24/7, against $11–35 for the mini. There is no meaningful resale either: the AM3+ board and the DDR3 together are worth less than shipping them.

Give it a job instead: rehearse the NAS. OMV, mergerfs and SnapRAID on junk drives — break the pool, rebuild it, restore from parity, twice. Work out the mergerfs create policy that keeps show seasons together. Practise the SnapRAID sync and scrub cadence.

It is also the right box to drill the IDE→AHCI switch, with initramfs and UUID fstab, and the NUT master/client split — because bricking it costs nothing. Powered off between sessions, all of that is free, and it stays a cold spare for the game server.

What to avoid is leaving it powered on "in case", doing nothing, at ~$100 a year.

Storage ports and bays

The board has six SATA, but the M.2 socket disables SATA 5/6 when populated — and it is populated, since the SK Hynix NVMe is the boot drive. That trade is already made, not hypothetical. The GPU takes the only x16 slot, so an LSI HBA is off the table and the x1 SATA card is the workaround.

The five drives on hand fit with room left. They use six of seven bays and six of eight ports, so there is one bay for a sixth drive. After that, bays bind before ports do — the eighth port would have nowhere to put a drive.

Boot costs nothing in this budget: the NVMe sits on the board, using no port and no bay. Growing past six HDDs means the NAS, not this chassis.

19 TB raw, and no parity. Two 8 TB drives plus three 1 TB. Nothing here is redundant — a drive failure loses whatever was on it, which is the argument for the NAS running SnapRAID rather than the media server growing indefinitely.

The three 1 TB drives are worth reconsidering. Each costs a bay and a port to contribute 1 TB, and consolidating them into one larger drive would free two of each — the scarce resources in this chassis are physical, not capacity.

Power draw

750 W puts you near 43% load, right by the Gold efficiency peak. A 550 W would have saved $50 but leaves no room for a future GPU.

UPS headroom

The CyberPower is 1000 W and could carry all three at about 65%, with even a simultaneous cold boot inside the envelope. Note the 1500 VA figure is not the constraint — active-PFC supplies run a power factor near 1.0, so the 1000 W rating is what binds.

It should not have to. Moving the game server to the BR1000MS drops this to ~475 W and takes runtime from roughly five minutes to ten — see the office split below. The figures above are the all-on-one case, kept as the ceiling to design against.

Runtime, not capacity, is the limit either way. Ten minutes is a graceful-shutdown window, not a ride-through — worth wiring up NUT or apcupsd before you rely on it.

Adding the NAS later pushes typical toward 770 W, around 77%, which is where headroom starts to matter. The 2000 VA version of the same unit is $449.95, so about $90 buys that margin if the NAS is a certainty.

Option B changes this arithmetic more than anything else on the sheet. The 705 G4 DM draws ~10–30 W against the FX-6300's ~160 W, which takes the BR1000MS from ~194 W to ~60 W — about 10% load, and runtime from roughly twenty minutes to over an hour. The unit stops being a shutdown window and becomes an actual reserve.

The interim APC is only 600 W. It carries the media server alone comfortably and two servers at idle with little to spare, but a simultaneous cold boot overruns it — exactly what happens when utility power returns after an outage. Until the CyberPower lands, stagger the boots in BIOS or run the game server straight off the wall. It is the one box whose sudden loss costs nothing.

Splitting the office load

Never plug one UPS into another. The downstream unit's charger looks like a nonlinear load with real inrush to the upstream one, most manufacturers forbid it, and the runtimes do not usefully add. Both office units hang off the wall independently.

Leaving the BR1000MS on 30 W of network gear wastes it. It is pure sine, so it is one of only two units in the house allowed to carry a server — and hours of network runtime buy little once the servers are already down. Put the game server on it.

The media server's runtime roughly doubles, from about five minutes to ten, which is the real prize. Both units land near half load, which is where their batteries last longest and run coolest.

The game server is the right one to move: it holds nothing that a sudden loss would damage, so pairing it with the older battery costs the least. Media and cloud — the two that hold data — stay on the newer, larger unit.

Both USB runs land on the N2+, so there is still only one shutdown path. Two units, two data cables, but one upsd and one master upsmon — every server is an identical slave pointed at U16. The simplicity that splitting the load used to cost has been recovered: you get the extra five minutes and one config.

The N2+ adds ~4 W to the BR1000MS, taking it from ~190 W to ~194 W. Not enough to restate the table.

Coming back up

Shutting down cleanly is the easy half. Coming back on is two separate settings, and neither is on by default.

1 · BIOS: restore on AC power loss. Set it to Power On, not Last State.

Last State reads as the safer option and is the wrong one here. NUT shut the box down cleanly, so the last state is off — and it stays off.

2 · The UPS has to actually cut its outlets. This is the step that gets missed. NUT's shutdown must finish by telling the UPS to drop the load, so it re-energises when mains returns — shutdown.return, issued by upsdrvctl shutdown at the end of upsmon's sequence.

Without it, the failure is specific: power comes back before the battery is flat. The outlets never de-energised, the servers never see an AC transition, and they sit there off until someone walks over and presses a button. A battery running all the way down does the right thing by accident — you do not want correct behaviour to depend on the outage being long enough.

Confirm each unit supports it before relying on it, because CyberPower's NUT load-shed support is less consistent than APC's: upscmd -l cyberpower should list shutdown.return.

3 · Test it the long way. Pull the plug and leave it — all the way down, outlets dead, then restore mains. Cutting the test short at "they shut down" only proves the half that was already easy.

Nothing on the monitoring panel can verify this. It sees a broken shutdown path; it cannot see a server that would never come back, because that only shows up during the one event you are building for.

WAN headroom

1 Gb symmetric is the enabler. Most residential plans give a fraction of that upstream, which is what usually makes self-hosting painful. Remote Jellyfin is the only real consumer:

The RTX 3050 runs out before the uplink does. NVENC handles roughly 8–12 simultaneous 1080p transcodes, so the GPU caps you well below the line. More bandwidth would not buy one extra stream.

Everything else is noise: game servers are 10–50 kbps per player, Immich sync is inbound and bursty, restic is incremental after the first seed and runs overnight.

The constraint worth watching is the mesh backhaul, not the plan — see the network design. Two wireless hops could hold the rack to 200–400 Mbps no matter what you pay for.

Sizing the panel VPS

2 vCore, 4 GB, 40 GB NVMe at $5/month. The instinct is that 40 GB is tight for a metrics database. It is not the constraint.

Five agents now — three servers, the NAS when it lands, and the N2+. Even with the retention job never written, that is roughly 2.6 GB a year, or a decade of headroom on 40 GB.

Set retention before the first agent connects anyway — but for the right reason. It is an index-size and query-speed decision, not a capacity one, and being clear about which problem you are solving stops it being deferred as "we'll deal with it when the disk fills". The disk will not fill.

4 GB is comfortable for Postgres, Caddy and the panel itself. The panel is a Rust binary in the tens of megabytes resident, so the database gets essentially all of it. Two cores are idle most of the time: a handful of agents posting every 15 s and an alert sweep every 60 s is not a workload.

Two things would break this sizing, and neither is planned: shipping logs to the panel rather than just metrics, or keeping full-resolution history for a year instead of rolling it up. Both are disk problems, and both are decisions rather than surprises.

Airflow

One 120 mm in (~70 CFM), two 80 mm out (~80 CFM) plus PSU exhaust. Slightly negative pressure.

Not a thermal problem — intake pulls through the drive cage, cooling the HDDs on the way past. It is a dust problem: unfiltered air enters through every seam. Blow the chassis out every few months.

If the P12 Pro has to run loud to hold GPU temps, drop to one rear P8 Max. Less exhaust, closer to neutral, quieter.

PCIe slots

One x16 (GPU) plus x1 slots. Two x1 cards want those slots: the SATA card and the NIC.

Verify the exact x1 slot count on your board before ordering both. If there's only one usable slot after the dual-slot GPU, something has to give — most likely the SATA card, with bulk storage moving to the NAS instead.

10 GbE is not possible here. It needs x4 or x8. 2.5 G over x1 is the ceiling.

Fan control on Debian

The hub is a dumb splitter, so lm-sensors and fancontrol drive it through the motherboard header. The real obstacle is the Super I/O driver.

Nuvoton chips need acpi_enforce_resources=lax at boot. ITE chips need the out-of-tree it87 module via DKMS — the frankcrawford fork is the maintained one.

Run sensors-detect after the build. If pwmconfig finds no PWM outputs, that's the ACPI lock, not the hardware. Fallback: set a conservative fixed curve in BIOS and move on.

Wiring the fans

Cooler stays off the hub so it tracks CPU temp independently. The hub reports RPM from slot 1 only — put the intake there, since it's the fan whose failure matters most.

Every server is dual-homed

Onboard gigabit to the GS116 for internet, SSH, web UIs and management. A second 2.5 Gb card to the island, where applicable, for NFS, Immich originals and restic.

Main LAN addressing is DHCP from the eero — reserve a fixed lease by MAC for every server so hostnames stay stable.

The rack sits four hops out

Modem to Bedroom to Kitchen to the BrosTrend switch, which fans out to the Eufy HomeBase 3 and to the Office eero. The Office unit then feeds the whole rack.

That makes the BrosTrend a single point of failure for everything in the rack. It is a $38 unmanaged switch carrying the entire WAN path — if it dies, the rack loses internet even though every eero is still up. Worth keeping a spare in a drawer; it is the cheapest insurance in the build.

It is at least on battery, sharing the BE850M2 with the kitchen eero and the Eufy, so a power cut does not take it out. Note this is the second reason that unit matters more than its size suggests.

Worth confirming the backhaul is wired. These are dual-band, so there is no dedicated backhaul radio — on a wireless mesh each hop shares airtime with clients, and this far out the rack could see well under half the 1 Gb service. Wired, it is a non-issue.

Note there are two 2.5 Gb switches in play. The Kitchen BrosTrend is ordinary LAN and carries the rack's uplink. The rack one is the isolated island and must never be confused for it.

The telemetry path is protected end to end

This wasn't planned and it happens to be right, so it is worth stating as a property of the design rather than leaving it to luck: the N2+'s entire path out of the rack — GS116, GS108, office eero — is already on the BR1000MS alongside the N2+ itself. The one machine that must keep reporting during an outage shares a battery with every hop it needs to do so.

Combined with the modem and both intermediate eeros upstream, the path from the N2+ to the VPS is on battery with no exceptions.

One ambiguity it does not solve. Because the link is wired-only, a dead GS116 or a bad patch cable takes the N2+ off the network along with all four servers. The panel still catches it — five agents going quiet at once is unmistakable — but it cannot distinguish the rack is down from the switch is down, and those are very different 2am problems. A ~$10 USB wireless dongle associating to the office eero as a backup path would resolve exactly that. Against it: a second interface on a box whose job is to be simple, plus route metrics to get right so it never becomes the primary path. Left undecided on purpose.

One Homebridge constraint while it is in mind: HomeKit discovery is mDNS, so the N2+ must stay in the same broadcast domain as the phones and the eero-attached accessories. Flat DHCP from the eero across unmanaged switches satisfies that today. If the main LAN is ever segmented, Homebridge is the thing that breaks first and least obviously.

Cable colours

Blue for main LAN, server onboard NICs to the GS116. Green for the storage island. White or red for the eero uplink.

Uniform correct lengths matter more than cable spec. Avoid Cat 7 and Cat 8 — marketing labels at these speeds — plus flat cable, braided jackets, and anything not stating bare copper.

What this gives up

The gaming tower and every Wi-Fi client reach the NAS at 1 Gb, since they arrive through the GS108 and GS116 rather than the island. Fine for occasional access, noticeable if you regularly pull large media off the NAS.

The fix is a 2.5 Gb card in the tower and a run to a reserved island port, or an 8-port island switch (~$60) to cover that and the future servers. Nothing here blocks either.

Three bundles, one side each

Power runs down one rear post, data down the other, exactly as the build order calls for. Drawing them as one bundle per service is the point — a cable you can trace by colour and side is one you can unplug at 2am without tracing it at all.

Hovering a device dims everything else, which is the quickest way to see what a given box actually depends on.

The APC sits on the floor beside the rack rather than in it, so the game server, GS116 and network shelf runs leave the frame at the bottom rear and terminate there. The 2U reserved for the second CyberPower stays empty until that swap happens.

Service loops are not drawn

Every run here is the straight-line path. Real ones need the 6–8″ of slack the build order specifies, so a chassis can slide out on its rails without unplugging.

That slack is why the 5 ft patch cables are more forgiving than the 1–2 ft the network design asked for, and also why they will coil behind the posts.

The network shelf

2U carrying the GS108, the 2.5 Gb island switch and the office eero. None of the three earns a U of its own, and the eero is taller than 1.75″, so a single U would not have cleared it. The GS116 nearly fills 19″ by itself and keeps its own.

Dropping the PDU paid for the second U. The bottom 2U is reserved for the second CyberPower rather than sitting empty. Everything still adds to twenty.

The N2+ took half of what used to be the spare 2U. The elevation summed to exactly twenty with no free U, so its mount had to come from somewhere: U16 for the N2+, U15 still genuinely spare. USB from U16 down to the CyberPower at U3–4 is roughly 4 ft internal, well inside the 5 m limit, and the BR1000MS sits on the floor at the same end.

The storage switch tray stays a separate print, and that was checked rather than assumed. Combining it with the N2+ mount into one 1U tray was considered and rejected: taking the island switch off the network shelf doesn't shrink that shelf below 2U, because the eero is taller than 1.75″ on its own. The combined tray would cost a real U instead of saving one.