Hacker News Reader

Comment by yxhuvud | Hacker News Reader

> Wow is it slow to POST

My understanding is that it is intentionally slow the first time you boot but should be normally slow after that. Apparently it is trying how fast it can clock the memory or something like that.

View on HN

It is _ridiculously_ slow on first boot after a cleared CMOS due to the extra memory training - as in minutes. 20 seconds to post is the normal time after that initial boot and a decent time at that for these boards.

Any idea why they're so slow to post? Or if this is something that can ever be fixed? The b550 (zen 3) board I replaced was way faster.

I wouldn't mind so much if suspend & resume worked.

Suspend + resume works for me on Windows, haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.

Not sure why they take so much longer. Zen 3 was definitely faster for me as well. I’m not holding my breath that it’ll get significantly faster but I suppose it’s possible an update could do it.

> haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.

Its probably just bugs in the 5.15 kernel I'm still running. Full zen 4 support wasn't added until linux 6.0, so I think I'm doing well as it is. Fingers crossed suspend is fixed by a newer kernel.

Given everything else in the system seems to work fine, I'm not too fussed.

First-gen products often have issues like this. My old X370 board (zen1 era) turns off and on again twice before actually booting; a similar zen3 system doesn't need that and boots faster in general.

it's doing DDR Training. It's not necessarily how fast it can clock the memory. It's essentially putting an oscilloscope to the memory traces and checking how to generate the necessary signals fast enough while still being recognized on the other end. Simply because at the clock speeds and latency requirements of DDR5 Memory, the signal path is unique enough between CPUs, Motherboards and RAM Sticks that you need to configure the clock generation individually for that setup.

That makes sense for first boot. But does it really have to do some variant of that every time the system boots up?

How would it know if you haven't changed your RAM?

Consider that using the same settings with different parts might lead to subtle instability, not a full on-boot crash.

Surely it can know that. Don’t ram chips identify with vendor / serial number etc?

Serial numbers that are supposed to be unique aren't necessarily unique. I would guess that the BIOS talk to an EEPROM on the RAM modules rather than to the memory chips themselves. It would be very easy for a manufacturer to flash identical contents to every EEPROM in a batch, or with a sequentially increasing serial, rather than bother with a database.

What if you reinsert the same RAM stick into the same slot? Minute differences in insertion force and direction can lead to the frequency response of the RAM stick changing. Data paths might now be a micrometer long and require the BIOS to retrain the communication controller to compensate for that.

DDR5 tops out somewhere around 8 Gigahertz clock speed, which means the data signals travel 3 centimeters before the next clock signal arrives. At those time scales it means you're going to have to align those data signals down to the micrometer if you want them to be properly received.

That sounds awfully fragile to me. Any kind of bump to the case could cause problems?

It could. Probably not for most minor bumps but reinsertion in the slot is more likely to cause issues than small bumps once insertion forces are being applied constantly. Hence the BIOS has to check.

I don't have one of these systems, but my laptop does a quite slow training process on cleared CMOS or new memory, and it definitely doesn't do it every time. I would imagine they only rerun this kind of thing if the SPD doesn't match the one from the stored training, or something along those lines.

Why wouldn't it run a subset of tests on each boot? It seems like it would be silly not to. That's probably one of the mechanisms by which the bios will automatically revert to "safe" settings after a botched overclock.

You could do an experiment. Remove some of the RAM modules and see if the 20 second boot time decreases.

On some level, the BIOS has to determine if new chips have appeared on the bus. But also check that conditions haven't changed.

If you took out a RAM stick and inserted it into the same slot, the conditions (due to dust, moisture, difference in seating) could be enough to throw off the reliability of the training data. So at minimum it has to verify the settings to be correct.

I'm not sure if it needs to take that long, however --- from my understanding, the training process has existed in some form since the early days of DDR and it's done by a sort of binary search (set the timings to one end until errors start appearing, then to the other end, and choose the midpoint). Maybe the newer generations are doing far more worst-case testing?

Training becomes more complex as you approach higher frequency domains. It's not simply a trivial binary search anymore as there is more than a few parameters (how fast the clock has to rise, how long you can and must hold clock and data lines for, what order data lines have to be held in, to compensate for speed-of-light lag, etc.)

I found this[1] page helpful in describing the DD4 training and calibration procedure. Though, while it's fairly involved, I'd be surprised if it took minutes to complete.

[1]: https://www.systemverilog.io/ddr4-initialization-and-calibra...

Reply on news.ycombinator.com