./ahmedhashim

I finally got around to updating the UEFI firmware on my desktop, an X570 board with a Ryzen 7 5800X that I built years ago and mostly stopped thinking about. Flashing the firmware resets every setting to factory defaults, so the standard prep is writing down what you’ve customized before the wipe. My list was short since I hadn’t really touched anything besides the boot order.

While I was inventorying the firmware settings, I checked what the memory was actually doing:

$ sudo dmidecode -t memory | grep -E 'Part Number|Configured Memory Speed'
	Part Number: F4-3600C16-16GTZNC
	Configured Memory Speed: 2133 MT/s

All four sticks were reporting the same thing. That part number is G.Skill’s encoding for DDR4-3600 at CL16, and the configured speed is what the memory controller actually trained at. The sticks were sold to run at 3600 megatransfers per second, yet they had spent their entire service life at 2133.

Defaults

Boards default to the JEDEC standard profile because it’s the one speed every DDR4 stick must support. The number printed on the box lives in a separate profile on the stick’s SPD chip. Intel platforms call it XMP, and ASUS boards on AMD call it DOCP. It runs the sticks at 1.35 V instead of the JEDEC 1.2 V, which is why it ships disabled.

Anything past the JEDEC baseline counts as overclocking, and firmware won’t overclock without being asked. G.Skill validated these exact sticks at that profile before selling them, so the risky part of this process already happened at the factory.

Infinity Fabric

On Zen 3 processors the memory clock does double duty. The Infinity Fabric that carries every core-to-core and core-to-memory transfer runs 1:1 with the memory clock up to about 1800 MHz. Going from 2133 to 3600 raises memory bandwidth by 69% and speeds up the fabric underneath every workload, whether it’s memory bound or not.

One setting

After flashing the firmware I set Ai Overclock Tuner to D.O.C.P. in the tweaker menu, picked the 3600 profile and rebooted. The first boot took a little longer while the controller retrained, but eventually it successfuly reported:

$ sudo dmidecode -t memory | grep -m1 'Configured Memory Speed'
	Configured Memory Speed: 3600 MT/s

All that remained was to test it.

Memtest

Four dual-rank sticks at 3600 is the heaviest load an AM4 memory controller can be asked to train, and unstable RAM can fail quietly as a corrupted file or a crash nearly impossible to reproduce. This can however be prevented by running memtest overnight to find these instabilities before they cost you anything.

On Arch with systemd-boot, the EFI variant is the one I needed:

sudo pacman -S memtest86+-efi

Plus a loader entry to boot it:

# /boot/loader/entries/memtest86+.conf
title   Memtest86+
efi     /memtest86+/memtest.efi

One gotcha bit me here: systemd-boot sorts entries newest first, and my loader config declared its default as arch while the entry’s real id is arch.conf. The pattern had never matched, so adding the memtest entry silently made memtest the new default. I needed to pin the exact id with default arch.conf before rebooting anything.

With the GRUB menu hidden on my machine, the clean way to run a test is a one-shot:

sudo bootctl set-oneshot memtest86+.conf
systemctl reboot

The machine boots memtest once and returns to the regular default afterward, so even an unattended reboot can’t strand it in a memory test. In the end, three clean passes by morning mitigated any concerns of the chips failing.

The fastest upgrade this machine has had in years cost nothing and was sitting in a menu the whole time. If you’ve never checked yours, dmidecode only takes a few seconds.