I suspect it’s mainly that BIOSes are badly coded. The DDR training space is well constrained with substantial information available via SPD, with the result levels, timings, terminations, voltages, and whatnot are readily predictable a priori. So it’s very likely a fairly convex and pretty simple multi-start optimization problem. Even if you’re doing single coordinate descent the limited number of steps means the parameter space for local searches isn’t that big. And I don’t know why you wouldn’t do block coordinate descent, stochastic gradient search, BFGS-L, or similar.
But from what’s actually happening I’m guessing AMD isn’t providing a lot of AGESA support and it wouldn’t surprise me if finding someone who wants to program a BIOS and who has a more or less introductory knowledge of optimization is pretty hard. It also looks to me like BIOSes are probably missing optimization basics like giving up on poor candidates and failing to set realistic convergence criteria.
That said, there is a poorly defined contract here about how much work the BIOS should at training time versus how much should be left for 12+ hour memory stability test passes. I think in some ways it’d be ideal if training always got it right, meaning it never let anything unstable through, but that’s incompatible with practical POST times.
Seems to me the whole thing’s gotten overdue for a rethink on mobos supporting overclocks. Like why not post off one channel at JEDEC default to bring up the BIOS UX, display progress while the other channel trains, swap channels, and repeat? That’d let people see what’s going on and you could implement basic stuff like cancel out to SPD defaults or a known good profile.
Moved to ignore as I’m not going to argue about whether a file on a USB stick is a file. Insisting a BIOS update invalidates fan curve control point locations that didn’t move because none of the hardware changed is equally silly.