Thanks for the explanation. Would you care to explain us how much slower is DDR3 in comparison to GDDR3 working at the same speed? I mean, latencies on DDR3 must be HUGE and that is something that will hurt WiiU a lot in comparison with PS3 or 360.
At the same speed there is virtually no difference in latency.
http://forum.beyond3d.com/showthread.php?p=1688344#post1688344
There is a small difference in write/read bus turnaround time, which reduces data bus utilization. But there is no difference in read latency.
I shouldn't speak for Grall, but he did use the word "typically", which really makes all the difference.
As has already been pointed out, that's not what he was referring to when he used the modifier "typically." If he's going to take such a hard stance on his correctness regarding an easily verified technical detail he should try harder to actually be correct.
Nice write-up. Now, to complement that, there should be a small expose regarding the circumstances where and why you don't actually achieve maximum bus utilization.
There are 3 main factors that contribute to lower data bus utilization:
1. Refresh
2. Read-to-write and write-to-read bus turnaround.
3. Not enough read or write transactions per row activate/page open.
Refresh is unavoidable for DRAMs. In all of the various DDR flavors it requires that all banks are closed and in the precharge state for some period of time before a refresh command and that no bank be activated/opened for some period of time after a refresh command. This creates a period of idle data bus. Depending on the exact version of DDR, the speed, and the operating temperature this forced idle period eats up anywhere from 3-10% of the theoretical peak bandwidth. Because of that you can never get above 90-97% of peak for anything but a short period of time.
Bus turnaround forces idle data bus cycles for two reasons.
On read to write switching there has to be some delay to ensure that the DRAM completes the read and the postamble and that the data makes it back to the controller before the controller can put the write preamble and write data onto the bus. Otherwise you wind up with IOs on both side driving the bus, which is bad for the IOs and corrupts the data.
On write to read switching, the DRAM requires that writes can not be followed by a read for a period of time. This is the amount of time it takes for the write to make it to the array so that a following read won't conflict with it.
Add those two up and a good controller tries to keep the amount of switching between writes and reads to a minimum. Ideally it buffers up a lot of writes while servicing a lot of reads, then it switches to writes for a while while buffering up reads, and so on. It can't wait forever though, since some reads might be latency sensitive (for example, CPU reads). So it has to balance between longer bursts of all reads or all writes vs latency and keeping everything flowing that is waiting for read data or for writes to complete.
Lastly, you need to, on average, generate more than 1 read or write each time you activate a row (open a page). All currently used flavors of DDR DRAM have what is called the "four activate window." This is a rolling period of time during which you can only issue an activate (page open) for 4 banks. If you've activated 0, 1, 2, 3, you can't activate 4 until the four activate time has elapsed since 0, and then before you activate 5 the time has to have elapsed since 1, etc...
tFAW for DDR3-1600 is 40ns, or 32 clocks. DDR3 is a burst of 8 for reads or writes and those take 4 clocks each. You need to do 8 reads or writes to those 4 opened pages to fill up 32 clocks. So for each page open you have to do, on average, at least 2 accesses. Any less and you are limited by tFAW and you force idle data bus cycles. With a 64-bit (8-byte) wide bus (like a DIMM), that means 8*8*2=128 bytes worth of data. For each page open you need to access 128 bytes of data to keep the bus full. For nicely ordered streams of requests (GPU pixel/texture ops, CPU stream operations, etc) this is easier to do. For scattered requests (CPU cache fetching) it is more difficult.
So if you are doing all reads or all writes and have a nice stream of addresses you can keep the data bus busy >90-95% of the time. Start mixing writes and reads and the % drops. Use an address stream which isn't as friendly and you drop even further. Make less than optimal arbitration decisions in order to give lower latency to CPU fetches and you drop even more.
