I know you're referring to ancient architectures, but the question of when to run refresh commands is still surprisingly interesting and relevant for DRAM contr

I know you're referring to ancient architectures, but the question of when to run refresh commands is still surprisingly interesting and relevant for DRAM controllers today. Just to clarify, with DRAM controllers I mean the piece of hardware inside a CPU/SoC/Chipset that receives memory read/write requests and talks to the actual RAM via DDR2/3/4/5. The later standards get progressively more complex so I'm not familiar with them, but for DDR2/DDR3 you have a window of a few thousand memory clock cycles in which you need to issue a certain number of refresh commands IIRC. Since those refresh commands take a while (relatively speaking), it can be a good idea to run them when the number of outstanding commands is low - or some other strategy depending on context. There are some more optimizations that DRAM controllers can perform. As part of reading a certain address, you first need to open a bank. This is not a free operation, it can take a while (relatively speaking). After the first read in a bank, you can read other addresses inside the same bank for free, without having to open the bank again. This means it makes sense for a DRAM controller to process reads out of order: Instead of processing a command sequence like A1 B1 A2 (A/B are banks here) in order, it saves time to process them out of order, i.e. A1 A2 B1. Disclaimer: It has been a while since I last looked into DRAM controllers, so I hope I didn't miss anything. But the general ideas should be correct.