Memory Performance: 16GB DDR3-1333 to DDR3-2400 on Ivy Bridge IGP with G.Skill
by Ian Cutress on October 18, 2012 12:00 PM EST- Posted in
- Memory
- G.Skill
- Ivy Bridge
- DDR3
The realm of DDR3-2400 MHz memory is reserved for two types of setup – strong Sandy Bridge and Sandy Bridge-E processors, or Ivy Bridge processors. The former can depend on the motherboard as well – within my motherboard testing I was finding that some motherboards enjoyed running at DDR3-2400 with an appropriate processor, whereas others needed a bump in voltages to get to work. For Ivy Bridge processors though, DDR3-2400 should be a walk in the park – based on overclocking results it seems that processors produced in Malaysia have good memory controllers, whereas ones made in Costa Rica have better processor speed/voltage characteristics (though your mileage may vary). So having a high and stable memory speed is ideally paired with an Ivy Bridge processor at this point.
As you can imagine, if DDR3-2133 was getting expensive, then DDR3-2400 is even much more so, even if the kit is rated C10 rather than C9. The additional cost comes mainly from binning – i.e. making sure that there are enough ICs to go into these memory kits. A 4x4 GB kit needs 32 ICs capable of running this speed, and to get those 32 may require north of 500 ICs to be tested (the rest get binned into other slower modules), though the exact numbers are obviously a well kept secret from G.Skill. If I recall, in the early days of Nehalem, the high end 2000 C8 modules were literally 1 in 100 that passed the tests, and hence the exorbitant price at the time. This DDR3-2400 C10 kit comes in at $145, not much of a leap from DDR3-2133 C9 at $130, but the benchmarks will paint a truer picture of how much this difference matters later in the review.
Visual Inspection
The DDR3-2400 C10 kit today provided by G.Skill covers its TridentX branding. TridentX is one notch above RipjawsZ, and spans kits from DDR3-2400 C9 to DDR3-2800 C11. The main features on the kit (aside from the speeds) are the heatsinks, to which G.Skill have added a detachable fin. Without the fin, the module is approximately 9mm above the module, and with the fin the total height is 22mm above the PCB. That is a lot of height for a memory module that in 99% of circumstances would not produce enough temperature to trouble any build.
In order to remove the fin there is a screw at each end of the module, and the fin slides off effortlessly. The fins fit very well, but upon attempting to reattach a fin I was unable to get it on as securely as it came out of the box, leaving a little wobble in the fin. There is no cause for alarm if you get a module with a wobbly fin – nothing is wrong, and it will not affect the heat dissipation as much as most users may think. Most modules output a few watts at best, so dissipation of several watts of energy without a fin is simple enough.
Putting such a large module in our TRUE Copper scenario was a recipe for disaster:
Even putting the module in the second slot faired no better:
All the testing for this review was done on a ASUS P8Z77-V Premium motherboard with the Intel stock cooler, so module movement is not much an issue in that case, but big air coolers still get a lot of usage (and is more often than not an investment over several updates), so there are things to consider when purchasing memory.
JEDEC + XMP Settings
| G.Skill | |||||
| Kit Speed | 1333 | 1600 | 1866 | 2133 | 2400 |
| Subtimings | 9-9-9-24 2T | 9-9-9-24 2T | 9-10-9-28 2T | 9-11-10-28 2T | 10-12-12-31 2T |
| Price | $75 | $80 | $95 | $130 | $145 |
| XMP | No | Yes | Yes | Yes | Yes |
| Size | 4 x 4 GB | 4 x 4 GB | 4 x 4 GB | 4 x 4 GB | 4 x 4 GB |
|
|
|||||
| MHz | 1333 | 1600 | 1867 | 2134 | 2401 |
| Voltage | 1.500 | 1.500 | 1.500 | 1.650 | 1.650 |
| tCL | 9 | 9 | 9 | 9 | 10 |
| tRCD | 9 | 9 | 10 | 11 | 12 |
| tRP | 9 | 9 | 9 | 10 | 12 |
| tRAS | 24 | 24 | 28 | 28 | 31 |
| tRC | 33 | 33 | 37 | 38 | 43 |
| tWR | 10 | 12 | 14 | 16 | 16 |
| tRRD | 4 | 5 | 5 | 6 | 7/6 |
| tRFC | 107 | 128 | 150 | 171 | 313 |
| tWTR | 5 | 6 | 8/7 | 9/8 | 10/9 |
| tRTP | 5 | 6 | 8/7 | 9/8 | 10/9 |
| tFAW | 20 | 24 | 24 | 25 | 26 |
| tCWL | - | 7 | 7 | 7 | 7 |
| CR | - | 2 | 2 | 2 | 2 |
Facebook
Twitter
RSS
114 Comments
View All Comments
frozentundra123456 - Thursday, October 18, 2012 - link
While interesting from a theoretical standpoint. I would have been more interested in a comparison in laptops using HD4000 vs A10 to see if one is more dependent on fast memory than others. To be blunt, I dont really care much about the IGP on a 3770K. It would have been a more interesting comparison in laptops where the igp might actually be used for gaming. I guess maybe it would have been more difficult to do with changing memory around so much in a laptop though.The other thing is I would have liked to see the difference in games at playable frame rates. Does it really matter if you get 5.5 or 5.9 fps? It is a slideshow anyway. My interest is if using higher speed memory could have moved a game from unplayable to playable at a particular setting or allowed moving up to higher settings in a game that was playable.
mmonnin03 - Thursday, October 18, 2012 - link
RAM by definition is Random Access which means no matter where the data is on the module the access time is the same. It doesn't matter if two bytes are on the same row or on a different bank or on a different chip on the module, the access time is the same. There is no sequential or random difference with RAM. The only difference between the different rated sticks are short/long reads, not random or sequential and any reference to random/sequential reads should be removed.Olaf van der Spek - Thursday, October 18, 2012 - link
You're joking right? :pmmonnin03 - Thursday, October 18, 2012 - link
Well if the next commenter below says their memory knowledge went up by 10x they probably believe RAM reads are different depending on whether they are random or sequential.nafhan - Thursday, October 18, 2012 - link
"Random access" means that data can be accessed randomly as opposed to just sequentially. That's it. The term is a relic of an era where sequential storage was the norm.Hard drives and CD's are both random access devices, and they are both much faster on sequential reads. An example of sequential storage would be a tape backup drive.
mmonnin03 - Thursday, October 18, 2012 - link
RAM is direct access, no sequential or randomness about it. Access time is the same anywhere on the module.XX reads the same as
X
X
Where X is a piece of data and they are laid out in columns/rows.
Both are separate commands and incure the same latencies.
extide - Thursday, October 18, 2012 - link
No, you are wrong. Period. nafhan's post is correct.menting - Thursday, October 18, 2012 - link
no, mmonnin03 is more correct.DRAM has the same latency (relatively speaking.. it's faster by a little for the bits closer to the address decoder) for anywhere in the memory, as defined by the tAA spec for reads. For writes it's not as easy to determine since it's internal, but can be guessed from the tRC spec.
The only time that DRAM reads can be faster for consecutive reads, and considered "sequential" is if you open a row, and continue to read all the columns in that row before precharging, because the command would be Activate, Read, Read, Read .... Read, Precharge, whereas a "random access" will most likely be Activate, Read, Precharge most of the time.
The article is misleading, using "sequential reads" in the article. There is really no "sequential", because depending if you are sequential in row, column, or bank, you get totally different results.
jwilliams4200 - Thursday, October 18, 2012 - link
I say mmonnin03 is precisely wrong when he claims that " no matter where the data is on the module the access time is the same".The read latency can vary by about a factor of 3 times whether the read is from an already open row, or whether the desired read comes from a different row than one already open.
That makes a big difference in total read time, especially if you are reading all the bytes in a page.
menting - Friday, October 19, 2012 - link
no. he is correct.if every read has the conditions set up equally (ie the parameters are the same, only the address is not), then the access time is the same.
so if address A is from a row that is already open, the time to read that address is the same as address B, if B from a row that is already open
you cannot have a valid comparison if you don't keep the conditions the same between 2 addresses. It's almost like saying the latency is different between 2 reads because they were measured at different PVT corners.