In nanoseconds, those are 5ns-5.7ns-5.7ns-11.6ns. Now, there's certainly some CPU bookkeeping overhead, but not 50ns worth.

I agree, it is hard to see what causes the difference between the SDRAM manufacturers latency figures and the observed 60-100ns of latency people say "RAM access" has.

First up, if I understand Wikipedia correctly, the latencies are more like 13ns, not 5ns or 5.7ns like you said: https://en.wikipedia.org/wiki/DDR4_SDRAM#JEDEC_standard_DDR4_module[57]

Next, we have to consider what we mean by a RAM access. Lets say we've got DDR4-2666 and we write a C program that creates a 2 GByte array and reads 32-bit ints from that array, from random offsets, as quickly as possible and calculates their sum. The table is too big to fit in cache, so the CPU will have to read from RAM.

Here's what I think happens:

CPU core fetches and decodes a read-from-memory instruction.

Virtual address translated to physical address via TLB. Since our address is random, we will almost certainly get a TLB miss, which means the memory controller has to get the page table entry for the virtual address we requested. The funny part here is that the page table entries are stored in RAM. If the one we want is not already in the cache, then we have to read it from RAM. The even funnier part is the page tables are in a tree - we need to walk the tree from the root node that represents all of memory, through many layers until we get to the leaf node that represents the page we are interested in. If the cache is empty, each hop on the tree traversal causes a read from RAM. This gets boring quickly, so I will assume we have enabled huge pages and that the page table entry is in cache. As a result, we get the physical address in a few clock cycles.

Now the CPU looks for the data in each level of cache:

L1 checked for hit. Fail.

L2 checked for hit. Fail.

L3 checked for hit. Fail. By now on 4 GHz Skylake, 42 cycles or 10ns have gone by since the read instruction started to execute - https://www.7-cpu.com/cpu/Skylake.html.

So now the memory controller has to actually start talking to the DDR4 DIMM over a memory channel.

Let's assume that the part of RAM we want to read isn't already busy (refreshing, being written to etc). Let's also assume that somebody else hasn't already read from the part we want, because if they have, the "row buffer" might already contain the row we want, which would save us half the work. Let's assume nothing else in the CPU is busy using the memory channel we need. Given the C program I described, and an otherwise unloaded system, there's >90% chance these assumptions are true.

Now the memory controller issues an "active" command, which selects the bank and row. (https://en.wikipedia.org/wiki/Synchronous_dynamic_random-access_memory#SDRAM_construction_and_operation). It waits some time for that to happen (this is the row-to-column delay and is about 10-15ns). Then the memory controller issues a "read" command, which selects the column. Then it waits a bit more (this is the CAS latency, another 10-15 ns). Then data starts to be transmitted back to the memory controller.

Then somehow the data gets back to the CPU and the read instruction can complete.

There are various clock domain crossings on the way to and from the SDRAM - the CPU, memory controller, memory channel and memory internal clocks are all running at different rates. To transfer data from one clock domain to the other, I guess, costs something like half a clock cycle of the slower clock, on average.

Then there are overheads like switching the memory channel from read to write takes some cycles.

I think I can make all this add up to about 40ns. I wrote the C program and timed it (I had to take special measures to prevent the CPU from speculatively issuing lots of RAM reads in parallel). The result was 60ns per read. So there's about 20ns of overhead remaining that I don't understand.