4gb (4 memory sticks) at 400Mhz on socket 939 MB -- timing is everything ...

[Bryan J. Smith]

On Sat, 2006-07-08 at 14:53 -0400, Peter Arremann wrote:
> Have you guys actually measured the impact of the memory speed? I'm running a 
> few servers - dual 280s with 4GB ram each - that run queries against a 
> smallisch in memory DB... this should be about as memory intensive as any 
> application can get (unless you're running UMA graphics). Some systems have 
> 266Mhz memory - others 400. It looks like even in this setup, all I can see 
> is less than 3% difference...

Depends on how much you write to memory (essentially no latency) and how
much you read from memory, it's burst length (size) and how random they
are (the greatest latency hit).

Remember, even though the synchronous timing is 2.5ns (400MHz effective)
for writes or burst reads (after the initial latency), read latency is
typically 20-60ns (only 16-50MHz!).  So the more you are reading smaller
chunks randomly, the more synchronous timing doesn't mean squat.

Although this is a mega-oversimplification (and _not_ actual), at DDR
200MHz (400MHz effective aka DDR400/PC3200), the last timing essentiall
mean ...
   4 = 20ns (50MHz)
   5 = 25ns (40MHz)
   6 = 30ns (33MHz)
   8 = 40ns (25MHz)
  10 = 50ns (20MHz)
  12 = 60ns (16MHz!)

That's what you're waiting on for the first few bytes!  Yikes!

At some point, if you're reading a lot of random areas of memory, and
your L1+L2 (possibly +L3) cache hit rate is closer to 94% than 97% or
so, you're going to be tying up the memory bus with a lot of wait.  The
_true_ dual-channel interleaved nature of S939/940 helps, but it's still
significant.


-- 
Bryan J. Smith           Professional, technical annoyance
mailto:b.j.smith at ieee.org     http://thebs413.blogspot.com
----------------------------------------------------------
The existence of Linux has far more to do with the breakup
of AT&T's monopoly than anything Microsoft has ever done.