This is why I only use boards that have the debug LCD. I am on AM4 now, but even DDR4 has training issues from time to time when you run XMP/EXPO profiles with tight timings.
1 Like
the issue arises from when you need to apply updates that necessitate reboot, especially things like kernel upgrades
this might work until you do a BIOS upgrade and it blows away all your hard-coded values 
Take a picture. It’ll last longer.
i actually do take pictures, but they tend to get lost in the phone’s camera roll after more than a few days. I had even “saved profiles” in the BIOS of all the settings, of course all my saved profiles got deleted during BIOS update…
Yup. And if you save to USB you won’t be able to apply them to the new version. Because apparently that’s just too hard for anybody at Asus, Gigabyte, or ASRock to figure out.
Maybe there’s boards that are exceptions but all the ones I’ve built require reentering everything by hand on a version update.
2 Likes
Where you might save your BIOS configuration backup is not the issue.
When any change is made to a BIOS image, the allocations for those saved values do not necessarily re-map and so are invalidated.
For example, let’s say you saved a value for tCL (a memory timing) of 0x20 that was written to memory location 0x0028af8a in the contiguous memory space of the BIOS as a backup, i.e. the area used to save your “profile”. (I’m making these number up as I go.) Then a new BIOS setting is added and it mapped to a lower memory location, it would bump every value by an integer step (for whatever an integer may be defined). When the old settings were “re-loaded”, it would load the wrong value for tCL from the wrong memory location and the system would likely fail to boot.
Short answer: New BIOS image invalidates everything, including previous saved profiles. To be even more clear, this is true for any firmware upgrade, regardless of device type. Previous saved profile values are wiped for the same reason primary values are wiped: they are INVALID.
The only way to “figure this out” would be to have a tool that re-mapped all your saved settings from the old BIOS profile to the new BIOS profile specific to each BIOS version in existence and for every different board. What a complete waste of time and not something that could be easily automated using existing UEFI functionality. That “tool” would have to be a Windows binary, a Mac binary, and a binary for Linux to make everyone happy because there’s no way in hell it’s going to fit in BIOS, especially with every new BIOS version released growing the re-map library for each new BIOS release.
Can you imagine the regression testing for such a beast? No, thanks.
2 Likes
On my threadripper box its usually pretty fast as well but when it trains it takes about 30 minutes to go through all 8 dimms and 768GB of chips. Training time definitely seems to scale with memory though, when I had 256 GB it was only around 10-15 minutes.
Debug LEDs are a lifesaver on DDR5!
Funny, while that was true for any of my ASUS bios updates (pretty annoying to run the fan tests again after every update), this never happened on my MSI board.
Seems to be an ASUS only issue 
MSI can do it.
1 Like
Not the ones I’ve built. But it’s also not like BIOS updates add, remove, or change settings and most of the potential complexity is self inflicted by mobo manufacturers having duplicate, triplicate, or quadruplicate menu items.
I also don’t get the argument about binaries and mappings. It’s not like putting a version number in a file format and writing if statements in a binary parser is hard. Or you could use JSON or XML or something.
Similarly, the serialization test cost doesn’t change and the deserialization cost is just reading previous saved versions. That’s um, adding iterations to a for loop.
2 Likes
Training time increases with the number of memory channels, not the number of DIMMs nor the density nor the total size of memory. Training is not an enumeration and test of all memory access locations.
Thirty (30) minutes to complete training is wildly excessive and suggests a large count of “auto” adjusted memory timings must be negotiated at each boot.
DO NOT ALLOW MEMORY TIMINGS TO REMAIN SET TO AUTO. HARDCODE ALL MEMORY TIMING VALUES EVEN IF SET TO WHAT AUTO MAY TYPICALLY RESULT.
1 Like
Happens all the time. This is a very common basis for modification of a BIOS image.
Not the point. Parser would have to know the memory location for each “setting” in order to re-map. This is analogous to declaring a variable on the heap in code and then expecting to know where in absolute memory that value would reside at runtime. I say absolute because BIOS firmware is an image, which is by definition absolute.
For example, go look at SCEWIN. The built-in export functionality will dump Setup Question (setting “name”), Help String, Token, Offset, Width, and Value/Options for each enumerated BIOS setting found. What it does not provide is absolute memory locations. Exposing absolute memory locations is a HUGE security risk. Exposing a trusted interface to read and modify values with controlled access is another thing…
2 Likes
I suspect they’re tired of receiving RMA warranty replacement and other technical assistance requests where users do not meet the competency level required to maintain and operate their system. They figure a forced mandatory re-train interval may alleviate their pain.
None of this would be needed in the first place if users simply changed all the auto settings to hardcoded values.
1 Like
I guess I missed something?
I have been building PC’s and being active in the enthusiast community for almost 35 years at this point, and I have never heard of “memory training” before.
Is this some new DDR5 feature? I haven’t actually gotten around to building a DDR5 system yet.
1 Like
8GB soldered-in RAM is fine
FAANG company saving $0.10 on BIOS chip per laptop, by allocating BIOS in the beginning of the SSD, is fine
1 Like
Even if a motherboard doesn’t do so automatically, it has always been recommended to reset your bios to defaults after every time the BIOS is updated.
Not doing so can have very unpredictable results. Sometimes even harmful (if voltage variables change)
has something to do with DDR5 and 4 dimms of memory.
I’m the opposite. I have never intentionally used sleep or hibernate.
I don’t usually use Windows, but when I do I always have “Fast Startup” disabled. I don’t want Hibernate masquerading as a shut down or boot. I want a clean load of system and kernel into RAM on every boot to minimize any instability or corruption problems.
Well, right there is your problem.
I used Gentoo for many years until I realized how much of a dumb hack it was and switched to a more reasonable binary package distributed distribution.
There is absolutely no benefit from compiling everything from scratch every time. The CFLAGs resulting in optimizations and hardware specific setting do little to nothing for performance.
it’s just a colossal waste of time and electricity just to result in a less stable system than a binary package distribution. 
“Memory training” is your DRAM controller trying to overclock the RAM beyond the specs given by JEDEC. To standardize memory training, Intel came up with XMP when DDR3 was new, and these are the presets that can be selected by your DRAM controller.
The training usually looks like this:
- Give the user mixed signals that indicate hardware failure or incorrectly installed CPU/RAM.
- Run a for loop over each XMP spec that the memory chips advertize to the memory controller.
- For each tried XMP spec, try to run the memory chips like this and test if this configuration is stable.
- Actually waste my time and fail every single XMP spec and fall back to JEDEC specs.
I have a really nasty feeling we wouldn’t be in this situation if we weren’t dumb teenagers trying overclock everything 20 years ago and bend over backwards to commodify overclocking.
I’m not going back to a binary distro because I had enough of incompetent package maintainers delivering broken packages and broken drivers. Maybe it works for you because maybe your use case does not involve video editing and shaders.
Edit: also binary distros like Ubuntu knowingly hire sex offenders. No thanks.