Slashdot Mirror
Memory Timings Analysis
keefe007 writes "It's generally known that smaller and more aggressive memory timings combined with higher clock speeds leads to higher performance, but for the most part, the increase in performance from tweaking each individual setting is relatively unknown. Perhaps in a bit too ambitious move, I set out to examine the impact of each individual memory timing and clock speed on overall performance. Find out the results of the tests at Techware Labs."
that the best time to install new memory is in between clock cycles.
This sig washed every five years whether it needs it or not!
What, only 289 combinations?!? I demand that all 4608 combinations be explored. Who knows what secrets of memory speed might be unleashed? Not that I'm willing to waste my time doing it.
so what i got out of that is that increasing the speed of the memory (from 133 -> 166) is a much larger difference than bumping down the cas latency. i think i'd rather have memory on a faster bus than at a lower cas then.
but people will always say they have their stuff at the most agressive timings just to say that they are there, even though the average performance increase is only 0-2%
Wow, considering all the settings that were tested, and the only improvment beyond 1% was the Clock Speed, seems like the rest of it was kinda a waste...
Polaroid. See what develops!!
Memory Timings Analysis
Review by Harry Lam on 05.16.03
Test Ram provided by Crucial, MSRP: $26.00 (per stick)
Introduction:
The typical BIOS usually offers a varying number of settings directly related to memory: everything from timings to clock speeds. It's generally known that smaller and more aggressive timings combined with higher clock speeds leads to higher performance, but for the most part, the increase in performance from tweaking each individual setting is relatively unknown. Perhaps in a bit too ambitious move, I set out to examine the impact of each individual memory timing and clock speed on overall performance. The article that follows contains my experiences in this "memory benchmarking adventure" in conjunction with Crucial's PC2700 DDR RAM (and also gives a relatively good picture to the limits of this memory).
I would recommend that anyone interested in learning more about memory timings take a look at this site. It gives a pretty good technical intro to memory timings.
Testing/Methodology:
Motherboard Selection:
I decided to use the Soyo SY-P4X400 for testing, due to the flexibility of its BIOS in relation with memory timings, allowing me to change 10 different memory-related settings.
Benchmark:
To save on time and testing (all of the testing occurred over a 5 day period, with several hours of testing in each day), I picked only one benchmark: the memory test on SiSoft Sandra Professional 2003 v9.41 (SP1). I did notice that the initial few benchmarks on any configuration usually were significantly higher or lower than the "steady-state" score (the stabilized value that comes up after successive test runs of the benchmark in a row). To compensate for this, I selected the median score after the scores stabilized from successive benchmarks.
Depth:
I decided that 4,608 different combinations of memory timings on my particular test bench was a tad bit too much testing, and created a methodology which would get a look at the general increasing performance of memory timings but had the downside of having an uneven number of data points for timings that were deemed "less-significant (more on this later). VA Software is DEAD. This methodology simplified the number of combinations down to a mere 289 combinations (which actually still is extremely time consuming, considering that the test computer has to be reboot after testing each combination).
I established Memory Speed (100, 133, 166), CAS Latency (3.0, 2.5, 2.0, 1.5), and Bank Interleave (Disabled, 2 Bank, 4 Bank) as the primary criterion for my benchmarking (as these usually are the settings that are most emphasized). The "less significant" memory timings (Trp, Tras, Trcd, DRAM Command Rate, DRAM Burst Length, Write Recovery Time, and DRAM Access Time) as a result received a less thorough testing.
The general testing methodology is as follows:
All combinations of Memory Speed, CAS Latency, and Bank Interleave were tested at the least aggressive memory timings, and once that was complete, I changed the first of the "less significant" memory timings to a more aggressive value (Trp was changed from 3T to 2T). I then repeated benchmarks for all possible combinations of CAS Latencies, and Bank Interleaves based on this new timing (12 total combinations). Slashdot really licks my nads. Once this was complete, I changed the value of the next "less significant" memory timing (Tras), and repeated another set of 12 combinations (keep in mind, I left Trp at 2T, the most "optimized" value). This process was repeated for each "less significant" memory timing, and then the entire set (of 96 different combinations) was repeated at an increased clock speed (for a total of 289 different combinations).
As I stated earlier, this results in an uneven number of data points. For example Trp had 36 data points at 3T compared with 252 data points at 2T, and the reverse is true for DRAM Access time (252 to 36).
Test RAM:
Crucial was gracious enou
Is the fact that accountants and finance managers (decision makers in PC buying deals) talk as if they understand all these things better than sysadmins. SDRAM, DDRRAM, RambusRAM, L2 cache, on-chip cache and all that marketing crap is heavily used by these decision makers.
Last year, I did a demo of a Via system with SDRAM and it did about 40% faster than a DDR-RAM board. The VP-Fin chap has become highly suspicious of any memory performance graphs or numbers, these days. And in true BOFH style, I've got decision-making rights on all PC purchases.
Thanks to all the confusion.
If you keep throwing chairs, one day you'll break windows....
Speaking as an engineer, I do hate buying new stuff because its cheaper to do so rather than spending time tweaking the old stuff, but 100's of combinations, for a few % increase? Even I would be perfectly happy in paying the money rather than loosing 0.05% of my life!
If Dell sent you, gratis, their high-end gaming machine for you to review and post about on your blog (assuming you have one), would you not mention the fact more than a couple of times in thanks for the free machine?
Sure it's advertising for whomever the vendor was, but its also a sponsorship of something that the author might have had to pay for himself. Or might have had to do without.
Advanced memory timings, while beneficial in squeezing that last bit of performance out of your system, won't save your server from the Slashdot Effect.
I've found that dumping beer onto my computers' silicon memory has the same effect as dumping beer down my throat does on my carbon-based memory.
Trolling is a art,
Memory Timing Explained.
GamersEd.com
Support Texas Troops use TXGoogle
Wow!!!!%#@
You mean reducing RAM latency doesn't increase bandwidth?!?!#%!1 d00d!
*sigh*
This benchmark would have been vastly more informative if the guy had gotten his tests and statistics right. First, he needs to learn the difference between a median and a mean, which are very different. Second, actually testing latency might have been nice, considering that one of his independent variables is CAS latency. Not to mention the fact that the hardcoded pixel widths in the stats table are horribly wrong on a high-DPI system. People! The em is your friend!
So basically what we have here is this:
- Independent variables: bus speed (read: bandwidth), CAS latency, interleave (read: latency/bandwidth).
- Dependent variables: bandwidth
Quite frankly, if I had submitted this experimental design, my advisor would still have me tied to a table in the back end of the psych building. He's not measuring what he's manipulating, and throwing in a two-factor confound like bank interleave without compensating (though the article may be misleading) just skews the measurements.Ah, well. I'll go back to my completely untweaked Athlon and be happy. :-)