Why is it that each generation of RAM seems to require an increased latency? I get why overclocking RAM often needs some relaxing of timings, but DDR4 is supposed to start at CL13 and I don't get why. I remember paying for CL2 SDR and CL2.5 DDR and it was fast (at the time) and just wondering why those sort of timings don't seem to be offered for DDR3 and 4.
I think it's because of the amount of times it's called upon to send parrallel information to increase bandwidth.. the turn around technology at either end is being flooded
I think that's it!
Ie the road is wider (for more lorries) but the blokes at either end loading and unloading the lorries work at the same speed so you gotta wait a tad longer for them
Originally Posted by Advice Trinity by Knoxville
oh I hope tha'ts right.... I think it is. I read an ARM bloke writing about it somewhere
YAY... found it
http://www.cadence.com/Community/blo...ing-worse.aspx
ik9000 (06-05-2014)
There are different types of 'latency' that you can measure when it comes to RAM speed. CL / CAS (Column Address Strobe) isn't actually a particularly useful measurement for the majority of people on its own.
Take a look at the table on WP: https://en.wikipedia.org/wiki/CAS_latency
Bit time goes down across the generations, so does cycle time, even though bandwidth is going up.
In short: You can't really compare just CAS rate as it's not useful on it's own. Even with it going 'up' across generations, latency is still better now.In general, the lower the CAS latency, the better. Because modern DRAM modules' CAS latencies are specified in clock ticks instead of time, when comparing latencies at different clock speeds, latencies must be translated into actual times to make a fair comparison; a higher numerical CAS latency may still be a shorter real-time latency if the clock is faster.
As the above really - the CAS rate is akin to the number of ticks you wait. When a new type of RAM is much faster then even a lesser delay in responding might be a higher number of ticks simply because each tick is much faster.
Yeah, I get that overall it's faster due to the faster clock rate, but it puzzles me why CAS doesn't just stay the same.
yes i get that, but whyyyy is CAS increasing? It's the gap between the request and when the data is delivered... and is in cycles, not time, so why is it always going up? Is it theoretically possible to do DDR3 at CAS5 but just not worth the cost? Or is it completely impossible?
Last edited by ik9000; 06-05-2014 at 09:12 PM.
from Zak's link it appears to be because each gen just parrallelises more of the same 200Mhz chips of the old days, so total latency scales (non linearly) with it. But DDR4 was supposed to be all new and re-structured.... so did they still not rethink that problem? And why on earth not, if that is the bottleneck. Surely there must be a refinement to be made....?
Greenberg started the ARM TechCon presentation by showing a chart, based on publicly available data, that predicts a DDR4 read latency of 22 clock cycles for the highest DDR4 data rate. The chart assumes an average latency of around 13.5 ns and is basically a plot of 13.5 ns against the clock periods of the various DRAM types. "Basically the DRAM cell array hasn't changed in the past 10 years," he explained. "At its core is a 100 MHz to 200 MHz array that has an access time of about 10 to 15 ns."
Because the substrates can't respond much quicker in a given generation - there's real physical processes going on and it takes a while for transistor gates to respond/reset. In time the manufacturing gets better and you get faster responding/resetting for the given voltage and you can reduce the number of ticks you have to wait. The amount of time in nano seconds is decreasing or at least staying the same (unless a new technology is so disruptive that the latency does slightly increase, but at a gain of transferring more information when it does give the answer etc. )
It has been attempted, but has ended in failure a few times: http://www.anandtech.com/show/3851/e...-afraid-to-ask
Even with the gate speed as Kalniel said, you also have heat to contend with when you change the timings due to the increase in operations on the chip. The two are related of course.The Hyper part was capable of high-speed, low-latency operation in tandem. Unfortunately, due to problems with long-term reliability, Hyper is now defunct. Corsair and perhaps Mushkin still have enough stock to sell for a while, but once it's gone, that’s it.
I think because unless you are a benchmarker obsessed with calculating Pi it just isn't important
You don't read a location in ram any more, you burst a cache line. Indeed you hopefully do that via a predicting pre-fetcher before the CPU even knows it needs it. You do that for for a queue of accesses coming from several out of order instructions in each of the several cores on the CPU. So you no longer want to turn around the next data read as quickly as possible, you want to tune for maximum throughput. across all the cores.
I think because unless you are a benchmarker obsessed with calculating Pi it just isn't important
You don't read a location in ram any more, you burst a cache line. Indeed you hopefully do that via a predicting pre-fetcher before the CPU even knows it needs it. You do that for for a queue of accesses coming from several out of order instructions in each of the several cores on the CPU. So you no longer want to turn around the next data read as quickly as possible, you want to tune for maximum throughput. across all the cores.
Dang nab it I'm a single threaded man in a multi-threaded universe.
And let's not forget ram banks are getting and trying to get bigger and bigger. Addressing bits are bigger, table is growing so naturally access is going to become slower. The only way to compensate with the current technology (I do not think they can reimagine the DRAM cell just like that) is to increase the operational speed and try and keep the latency as low as the system can tolerate. On my opinion in general the systems try evade the problem than solve it, usually by moving the bottleneck somewhere else. Maybe because its unsolvable or maybe because it is easier and more cost efficient to fund research about cache prediction and in general optimisation of the use of multiple level caches (even with on die DRAM) than the actual speed up of system memory. In a multiprocessor system things get even more complicated so there are a lot other factors that could really ruin a possible memory operation's speed if not implemented correctly so I guess we'll just have to wait...
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
