Memory Latency - Cachemem

The other useful number that Cachemem can produce as a benchmark is latency, in this case we chose the worst-case scenario to show you how much memory latency can vary. 

First of all you must have an understanding of what memory latency is.  We have been talking about bandwidth quite a bit and that can be equated to the amount of data you can get from one place to another at a given moment.  Latency is the amount of time it takes before you can actually transfer data. 

With our love for car analogies here at AnandTech, we'll provide one for bandwidth and latency:

Once a car gets moving it can travel at 60 mph (bandwidth), however the time it takes to get to 60 mph, or its 0-60 time, is also a factor in performance as well (latency).

This above graph is quite possibly one of the most important in this entire comparison, so pay close attention to it.  When dealing with latency figures, the numbers are reported in cycles and obviously the lower the number the better (the quicker your 0-60 time).  Remember how confused we were when the MAGiK1 with PC1600 DDR SDRAM provided such low memory performance scores in the past few tests?  Take a look at its latency, 374 cycles!  That's almost 2x the latency of the AMD 760 running PC1600 DDR SDRAM.  There is definitely an issue with the MAGiK1 or its implementation on the A7A266 when it comes to performance regarding PC1600 DDR SDRAM.  A similarly large latency penalty is incurred when running the solution at 1000/100 with PC133 SDRAM.

Even with PC2100 DDR SDRAM the MAGiK1's memory latency is worse than that of a KT133A running at 1000/100 with PC100 SDRAM.  The only time the MAGiK1 is able to redeem itself is when running at 1000/133 with PC133 SDRAM, where it remains competitive with the other solutions.

Although DDR SDRAM is inherently a higher latency solution than regular SDRAM, AMD's DDR memory controller in the 760 chipset seems to be able to offer very quick access to the memory.  If you remember back to what SuperBypass actually did on the AMD 750 chipset, it helped reduce memory latency through some internal tricks perfected by AMD, this could be the result of SuperBypass on the AMD 760 chipset. 

Here's another interesting thing to look at; if you note that the difference in latency is negligible between the KT133A running at 1000/100 with PC133 SDRAM and the same setup with PC100 SDRAM it can be said that moving from PC100 SDRAM to PC133 SDRAM on the 100MHz DDR FSB does not increase latency.  Now look at what happens when the FSB is set to 133MHz and the memory bus is set to the same (PC133), the latency drops by 30 cycles.  It looks like we've found the explanation behind why the KT133A has been so great of a performer when running at the 133MHz FSB: it's memory latency.

While at Computex last year Iwill told us that they weren't too keen on the idea of allowing users to run their FSB and DDR memory frequencies asynchronously, this may very well be why.  Running your memory and FSB synchronously seems to result in quite a bit of a latency reduction which currently helps performance quite a bit because very few of today's commonly run applications are memory bandwidth limited, instead they are often affected more by memory latency.

This would explain why the KT133A does so well in spite of only using PC133 SDRAM.  Keep these benchmarks in mind as we take you through our suite of real world performance tests.

Memory Bandwidth - Cachemem Overall System Performance
Comments Locked

0 Comments

View All Comments

Log in

Don't have an account? Sign up now