Even if it’s powered, RAM will lose its data on the order of a tenth of a second. RAM doesn’t just require power, it requires that your computer constantly read and rewrite it - so every 64ms your computer has to read every gigabyte of RAM and write it back.
Yes - it’s been the job of the DRAM controller for almost the entire history of computing. But that’s still a part of the computer and if it stops working then your RAM will go blank in a fraction of a second
It’s been a very long time since my computer engineering course, and we didn’t cover this topic specifically, but I highly doubt it’s a full dump and reload. What likely happens is each ram address has a ttl flag or some way for the CPU to know when to rewrite the data, and it does it as needed.
Plus, the bus between the CPU and ram is ridiculously fast. Your pc could dump and reload all of its ram in the time it takes you to blink. And, with multiple cores, the task can be allocated to a single core, or divided up among all of them.
Modern RAM just needs to be told to refresh. The device itself will go through the refreshing process. But the whole array needs to be refreshed, there’s no LRU scheme to tell what bank or row was last accessed.
Starting with DDR3 it’s not so easy. Density is so high that reading or writing one row affects cells in adjacent rows. Partial target row refresh (PTRR) counters this, where any access of a row is followed by a refresh of adjacent rows. Flaws in this process in early DDR3 controllers was at the heart of rowhammer exploits, where repeated accesses to a memory location could work out what’s stored in physically adjacent memory, even if it’s not privileged. IIRC DDR4 pulled the PTRR process into the RAM’s built in refresh circuitry so it’s transparent to the memory controller.
At least on older x86 motherboards, there used to be a dram refresh interrupt. It would trigger every 15 or so milliseconds and tell the dram controller to do a bus hold request and then refresh the ram. This bus hold request means the cpu can’t access the ram when this happens (it can still run stuff in the cache) but at least you aren’t wasting as much cpu time on dram refresh this way.
Some very early systems did do it at kernel level, but yeah you are correct. Though I’d also consider the dram chips to be part of the computer and DRAM refresh makes up a good part of your phones battery consumption at standby.
If I remember, the decay of information in RAM is slower than that. This is an old memory, but I recall I think someone on TechTV talking about how you could, if fast enough, remove a module from one machine and put it in another, and if done right, potentially get the information off it.
It’s possible, and can be done at home. You need to literally freeze the RAM very quickly (typically with CO2) and transfer it to the new system. Then you dump the contents of the stick and hopefully find an encryption key.
From what i’ve read it’s temperature dependent, and at room temp some dram cells might take as long as 10 seconds to decay. The 64mS refresh is a super conservative call because it’s really bad when random bits go missing out of memory. The decay is faster at high temperatures, but some dram controllers might actually adjust based on temperature.
it is temperature dependent, if you change this refresh timing in the BIOS to the tightest possible value at a given temperature, you can easily make your PC crash by heating the RAM up a bit (for example by removing a fan)
Note that when you freeze the RAM a lot, it will hold the data for up to seconds (if I remember correctly). This is used in hacking - you can get the contents of the RAM after the computer has been shutdown.
Even if it’s powered, RAM will lose its data on the order of a tenth of a second. RAM doesn’t just require power, it requires that your computer constantly read and rewrite it - so every 64ms your computer has to read every gigabyte of RAM and write it back.
Doesn’t the ram do that itself? Otherwise reading/writing all that data would waste tons of time for the CPU.
Yes - it’s been the job of the DRAM controller for almost the entire history of computing. But that’s still a part of the computer and if it stops working then your RAM will go blank in a fraction of a second
It’s been a very long time since my computer engineering course, and we didn’t cover this topic specifically, but I highly doubt it’s a full dump and reload. What likely happens is each ram address has a ttl flag or some way for the CPU to know when to rewrite the data, and it does it as needed.
Plus, the bus between the CPU and ram is ridiculously fast. Your pc could dump and reload all of its ram in the time it takes you to blink. And, with multiple cores, the task can be allocated to a single core, or divided up among all of them.
Modern RAM just needs to be told to refresh. The device itself will go through the refreshing process. But the whole array needs to be refreshed, there’s no LRU scheme to tell what bank or row was last accessed.
Starting with DDR3 it’s not so easy. Density is so high that reading or writing one row affects cells in adjacent rows. Partial target row refresh (PTRR) counters this, where any access of a row is followed by a refresh of adjacent rows. Flaws in this process in early DDR3 controllers was at the heart of rowhammer exploits, where repeated accesses to a memory location could work out what’s stored in physically adjacent memory, even if it’s not privileged. IIRC DDR4 pulled the PTRR process into the RAM’s built in refresh circuitry so it’s transparent to the memory controller.
At least on older x86 motherboards, there used to be a dram refresh interrupt. It would trigger every 15 or so milliseconds and tell the dram controller to do a bus hold request and then refresh the ram. This bus hold request means the cpu can’t access the ram when this happens (it can still run stuff in the cache) but at least you aren’t wasting as much cpu time on dram refresh this way.
Slightly misleading, the DRAM chips do that themselves so the kernel doesn’t have to do that.
Some very early systems did do it at kernel level, but yeah you are correct. Though I’d also consider the dram chips to be part of the computer and DRAM refresh makes up a good part of your phones battery consumption at standby.
If I remember, the decay of information in RAM is slower than that. This is an old memory, but I recall I think someone on TechTV talking about how you could, if fast enough, remove a module from one machine and put it in another, and if done right, potentially get the information off it.
It’s possible, and can be done at home. You need to literally freeze the RAM very quickly (typically with CO2) and transfer it to the new system. Then you dump the contents of the stick and hopefully find an encryption key.
From what i’ve read it’s temperature dependent, and at room temp some dram cells might take as long as 10 seconds to decay. The 64mS refresh is a super conservative call because it’s really bad when random bits go missing out of memory. The decay is faster at high temperatures, but some dram controllers might actually adjust based on temperature.
it is temperature dependent, if you change this refresh timing in the BIOS to the tightest possible value at a given temperature, you can easily make your PC crash by heating the RAM up a bit (for example by removing a fan)
Note that when you freeze the RAM a lot, it will hold the data for up to seconds (if I remember correctly). This is used in hacking - you can get the contents of the RAM after the computer has been shutdown.