DDR4 timings explained 1: tCL tRCD tCR // Literally just a single read burst operation 

in short: because they chose the cheap way to not add a mem_active_state flag to the memory chip.

You should probably pin your comment :P

@@fabiotiburzi Are you insane? That would effectively double the latency of a RAM chip. There's a reason as to why it's built this way - the same reason as to why UDP exists as an alternative to TCP

@@davemichael1859 it depends: if a ipothetical manufacturer implement that function in a good way, the latency will not be afflict

​@@davemichael1859 Signal travel time is a miniscule part of the overall latency. The current way of blindly waiting and guessing when the memory chip might be ready doesn't sound like the best possible solution if cost were of no issue.

Literally this. All I knew before is lower numbers is better but not why.

yeah, nobody else goes in so deep on RAM topic and at least I personally find this super interesting - probably most fascinating out of all major PC components - because there's just so much to controlling it and now I'm already convinced how dumb RAM is :D

True. And I would like to learn more.

+1 here

Micron publishes the white paper on their memory chips, so it's all in there. It's the one he showed on screen in the last instalment.

@@andersjjensen That one I already have. The one he showed in the previous video is an older revision S, from the end of 2020, that is 10 pages longer than the current revision T, from 2021, that is directly available from Micron. Cool of Micron to share such complete datasheets. The Samsung one I have is quite a bit shorter.

In this simple scenario, yes. But as CR is the sending duration of a command and timings are "delays" between events (i.e. the end of sending of a command like ACT or READ and the next one), no. It depends on the specific situation a timings applies to and what is happening else. Some timings might suffer even more than +1 cycle on 2T CR.

so depending on the chip width the columns are either 4 8 or 16bits deep. The whole memory stick is 64bits wide. So each column output from a memory stick is 64bits(either from 4 8 or 16 mem chips).

Bits. To be specific according to Micron's documentation on a 288-Pin DDR4 RDIMM """ DQ represents DQ[3:0], DQ[7:0], and DQ[15:0] for the x4, x8, and x16 configurations, respectively. If cyclic redundancy checksum (CRC) is enabled via the mode register, the CRC code is added at the end of the data burst. """ So, it can be 4, 8, or 16 bits. Interestingly, looking at the register description from a Viking datasheet, CAS latency is actually set on the RAM chip itself. Well, the memory controller and the chip. Otherwise they couldn't stay in sync. There are also two bits for Burst Length (BL). You'd think that means it tops out at 4, but a BL of 0 doesn't make sense, and it's common to apply multipliers to these things. I mean, a BL of 4 doesn't even make sense in the example provided.

@@arthurmoore9488 Does the burst length mean how many cycles it keeps the data on the data queue ? That is, if you want to read 4 columns, you have a BL of .. say, 1, if you want to read 8 columns, a BL of 2 and if you want to read 16 columns, a BL of 3 ? Or 0 (aka as 4, to keep the multiplying idea) ?

@@Winnetou17 burst lenght is how many columns the chip outputs in the burst. DDR4 has Burst Chop 4 and Burst Length 8.

Important to note, this is the absolute worst case scenario for a read command. As we will see in part 2,* locality really matters. It's the difference between getting books off a shelf, having to go to another floor, and having to go to another building. Mind you cache blows RAM out of the water. Especially when you're talking about directly connected cache and not something that has to go through the interconnect. Which brings up it's own headaches since not only do you have that "Layer 4" cache, but even within a chipplet, it's common to share the L3 cache, with only L2 being per core. With hyper-threading even then that cache is shared between both threads! Oh, and what's the associativity of the cache? That determines how well the CPU handles data that is spread out versus data that is packed together. Regardless of all of that, the answer is always the same. It comes down to how well the developers have optimized the code, what the memory access pattern actually looks like, how the data is actually laid out in RAM, and if data access even is the bottleneck. Seriously, game studios have policies like don't use the C++ standard library. Use our "proprietary" internal library instead. We determined it was faster 2 decades ago. Guess what? That means if something isn't in the library, then a developer is going to have to re-invent the wheel (poorly). Also, is that internal library really faster? I could go on, but hopefully you get the point. * hopefully there will be a part 2.

@@arthurmoore9488 yeah and the bottleneck is still latency. We moved cache onto the cpu because it’s lower latency. Cache is a latency tolerance technique just like hyper threading and more. Fps games are inherently random accesses. I can tell you not only from personal experiences but latency measurements. Cr1 or fake memory oc as well.