Checking My Own Work: What I Found When I Audited My Three PCs

The short version

I built three computers the same way, and I made the same mistake on all three: both memory sticks went into the same memory channel. The computers worked fine. They were also running their memory at 3600 MT/s instead of 4800, and with half the memory bandwidth on paper. I found it while tuning one of them, fixed two in a single evening, and the third is next on the list. This post covers the mistake, how to check yours in two minutes, and a few other things I cleaned up along the way.

What I did wrong

All three computers use the same motherboard, an ASUS ROG STRIX X870-A GAMING WIFI, with a Ryzen 5 7600X processor. The board has four memory slots but only two memory channels. The slots are labeled A1, A2, B1 and B2, and when you install two sticks, the board wants them in A2 and B2, one per channel. I put both sticks in the same channel. That limits the system to single-channel memory, and with two sticks sharing one channel, the board also holds the memory speed down at 3600 MT/s.

How it happened: the paper that came in the box was thin and its slot diagram was hard to follow. I read it wrong, and then I repeated my own mistake on the other two machines because I built them all the same way.

The fix

Moving one stick to A2 and the other to B2 took a few minutes per machine and a screwdriver. My first boot after the swap looked dead for a bit, with a black screen and an amber warning light, before it came up.

Afterward, the memory report on both fixed machines shows one stick in channel A and one in channel B, both running at 4800 MT/s. That is a third faster in speed, and now it is dual-channel.

Did it make the computer feel faster? I tried to measure it, but my benchmark results were too noisy to prove a difference on small jobs. I trust the memory report more than the benchmark numbers, and I would rather tell you that than make up a percentage.

The better test turned out to be a game I play, Rust. On both fixed desktops it now runs at roughly 80 to 110 frames per second at medium detail. I did not record a before number, so I cannot tell you how much of that came from the memory change. But it is a real-world result, which counts for more than a synthetic benchmark.

How to check yours in two minutes

On Linux, run this in a terminal:

sudo dmidecode -t memory | grep -E "^\sSize:|Bank Locator:|Configured Memory Speed:"

Each slot prints three lines: its size, its channel, and its configured speed. Look at the slots that show a real size. If one is on CHANNEL A and the other on CHANNEL B, you are in dual-channel. If both are on the same channel, you are in single-channel, like I was. On Windows, the free CPU-Z program shows the same thing on its Memory tab, on the line that says Channels.

Before you move anything, read the slot labels printed on the board next to the sockets. Those are more reliable than the paper in the box.

Cleaning up a drive that was almost full

One of my computers runs around the clock and stores my nightly backups. When I checked it, the backup drive was nearly full, and so was the system drive.

The backups. Each nightly backup is a full copy of about 650 GB. The job that made them kept every copy until it was more than a week old, and it wrote the new copy first and only then deleted the old ones. That meant the drive needed room for eight or nine copies at once. When a night ran out of room, the job left a half-written file of roughly 600 GB behind, and that leftover ate even more space. I checked that nothing was using the leftovers and deleted them, tested the newest good backup, and removed the three oldest copies.

The permanent fix is one added line in the backup script. Before it writes tonight's copy, it deletes everything except the newest three. I also cut the age limit from seven days to three as a second safety net. The next morning the drive held four copies, 2.6 TB, with 3.9 TB free of its 7 TB limit instead of about 1 TB.

The system drive. The main drive was 72% full, and most of it was my own home folder. The biggest single item was a 25 GB folder I had already marked "hold to delete." I did not delete it. I copied it to another computer, ran a checksum comparison to prove every file matched, and only then removed the original. The drive dropped from 72% to 46% full.

I also ran the delete command on the wrong computer first. The folder did not exist there, so nothing was lost, but it is a good reason to read the prompt before you press Enter on anything that deletes.

Making my status panel tell the truth

I keep a small status panel on my desktop for each computer (I use Conky on Linux), showing CPU, memory, drives, and more. After the memory fix, it still showed 3600 MT/s. The reason is that Conky cannot read the hardware report without administrator rights, so my script was reading a saved copy of that report from weeks earlier. A saved copy never updates.

The fix has two parts. A small script, run by the system at every boot, writes a fresh hardware report to a temporary file that any user can read. The panel script now reads that file instead of the old copy, so the memory block shows each stick's real speed.

Then I added a backup block to the panel for the computer that holds the backups:

• Status: OK in green when the newest backup is under 30 hours old, LATE in yellow up to 54 hours, and STALE in red after that.

• Details: when the last backup ran, and how many copies are kept.

• Stuck files: a line that says a backup is being written (normal while it runs) or warns when a half-written file has sat for 8 hours or more. That is the failure I missed before.

I made the same changes on a second computer, since its panel works the same way.

Chasing a network card that kept dropping

Earlier this fall, the network card on two of my computers dropped out and stopped seeing the cable, a day apart. They are the same build, so I suspected the same cause. The chip is an Intel I226-V. People report on Linux mailing lists and forums that it can disappear ("PCIe link lost, device now detached") when a power-saving feature called ASPM is on. The usual fixes are a BIOS update, or turning ASPM off in the BIOS or with a kernel option.

I am not changing any of that yet, because I do not have evidence that it is my problem. When I went looking, the system logs on my desktop only went back to the last reboot, so anything from October was already gone. The first fix is to make the system keep its logs across reboots, so the next drop leaves a record. Then I wait for the next drop, search the log for "link lost," and only change the power-saving settings if the log points to them. One change at a time, with proof, beats changing five settings and never knowing which one helped.

While I had the BIOS open, I also noticed two settings that matter on a computer that runs unattended: one that stops the boot and waits for a keypress after an error, and one that decides whether the machine turns itself back on after a power outage. I plan to look at both when I do the memory swap on the computer that runs around the clock.

What I would tell anyone building a PC

• Read the slot labels on the board itself, not just the paper in the box.

• After you build, check that your memory is dual-channel and running at its rated speed. A computer that boots is not the same as a computer that is set up right.

• Anything that runs on a schedule needs a limit, so it cannot fill a drive.

• If you trust a number on a screen, make sure it is reading fresh data.

I spent years building custom PCs at Cloud 10 Computers, and I still made this mistake three times. That is the best argument I know for checking your work. If you have a computer or network question, or want help checking your own build, ask in the comments or on the site.