 |
|
By Michael Schuette: Sunday 18 May 2003, 12:41 and taken from www.theinquirer.net who in turn stole it from Techinsider.
MEMORY REVIEWS have become something like pet peeves, they are easy to conduct, hardly take any time and allow to rate one DIMM over the other according to the differences in benchmark results. The favorite tools are is SiSoft Sandra and PCMark2002, which give the precise bandwidth of each module tested. Suffice it to say that it is true, different memory modules may offer different performance. Keep in mind, however, that these differences will show only if different modes of operation are applied. The point is, that memory modules are entirely passive devices that can only execute commands given by the controller. The output resulting from these commands has to abide by precise timing rules that are independent of the module and only reflect the timing characteristics of the chipset and selected PCI registers, commonly referred to as BIOS settings.
The result is that the memory module or DIMM can either comply with the timing rules defined by the memory controller or else fail. However, no module can run faster or slower than what the chipset specifies. Keep in mind that the functional relation between a DIMM and the memory controller is about as flexible as the play allowed for the timing belt in an engine. Therefore, in a perfect world, all memory modules would perform identically.
The world is not perfect, though. The predominant factor causing differences in memory bandwidth performance revolves around differences in the DIMM slot state machine that would define different latency settings and, therefore, different rates of data requests and transfers. In other words, as mentioned above, if the BIOS settings that specify the latencies are changed, the outcome of the benchmark will be different. Now, this was easy, wasn't it?
However, there are some other factors contributing to differences in memory benchmarks that are independent of the latency settings. Some of these problems originate from within the hardware, others are software or system-dependent.
On the hardware site, the easiest problem to eliminate is spread spectrum modulation which changes the bus frequency and, therefore, also the memory scores. Another factor often overlooked is the internal organization of the DRAM components, that is, different chip densities will have different numbers of rows, and, most importantly, will spread over different numbers of physical banks. One example is to compare 128Mbit technology with 256 Mbit technology; in both cases, the most likely module density will be 256 MBytes at the cost of either eight or 16 chips. The number of chips is not the problem, however, in the case of 128 Mbit components, their distribution over two physical banks (based on x8 width) adds a small amount of latency to the overall performance of the memory.
The reason is that testing of � of the total memory density will include toggling between the two physical banks. Because of the associated extra chip select latency, the bandwidth will be lower than for a single physical bank, which is what happens in case 256 Mbit parts are used in a single bank configuration. The actual page size is identical; all current designs use 1 k column addresses per row, therefore, hitting page boundaries will not play a role here. Keep in mind also, that the actual memory performance will still be the same, only under conditions where a huge array of memory is tested will there be the additional delay of bank switching and this is actually a memory controller latency rather than a DIMM latency.
More variables are caused by the system software that is, memory fragmentation caused by any program or service running in the background. Fragmentation is influenced by the uptime of the system before the benchmark is started. Every program occupies its own memory space and Sandra has to work around those blocks of memory. Most programs will attempt to maintain a virtual contiguous address space, however, "virtual" means software translation of addresses and, therefore, the physical addresses can be scattered all across the entire memory address space in a random fashion. Random, in turn, means random. Hence, no two boots will write the same data to the same addresses. Consequently, the conditions under which the benchmark is running change from one run to the next, regardless of how it is done, unless the benchmark is reconfigured to define a specific address range that is excluded from system memory usage, similar to the AGP aperture. This is possible but currently not supported.
Memory fragmentation will have some impact on the outcome of any memory benchmark and get worse with increasing time of the PC after boot-up. Therefore, even opening a small window somewhere or running another application prior to executing the memory benchmark will cause the scores to deteriorate. The easiest way to show this effect is to run repetitive iterations of SiSoft Sandra memory benchmark without intermittent reboots. On most systems, each consecutive run will return a different score, typically lower than the previous until the system reaches a plateau, typically on the 3rd to 5th rerun.
Those differences are relatively small and are usually in the order of approximately 1%. For example, our Intel D875PBZ running dual channel DDR400 returned bandwidth measurements in the range of 4821 to 4905 MB/sec. Therefore, if we see differences in memory scores in the order of 1/10 % being used as basis for a performance rating between brands or modules, we have to scratch our heads in awe and wonder and congratulate the reviewers on finding performance differences that don't exist.
Keep in mind that SiSoft Sandra is an excellent tool but like any other tool it is only as good as whoever uses it. -End Quote
MY personal opinion is that if you get a maximum memory bandwidth score out of numerous tests (say 3+) then you can gleam your white teeth and say that you have done it gleefully posting your highest score . If everybody does this honestly and with at least SOME stability of their OS I do not perceive this to be a problem in the least.
And, in regard to the maximum throughput of a chipset/northbridge I believe that if overclocking that chipset, beyond it's designated stable rate -causes a shortening of the life of that northbridge or chipset PART. -end