Memory Write and Copy Performance


EVEREST
Memory Write Performance @ 333MHz FSB

Memory write performance is almost solely dependent on FSB, although changes in absolute CAS latency can have a much smaller secondary affect. There is no clock crossing procedure needed when moving data across the FSB onto the memory bus during write operations; therefore total memory throughput is based largely on the speed of the interface and nothing more. DDR3 shows improvements over DDR2 in this regard.


EVEREST
Memory Write Performance @ 400MHz FSB

The trend carries on through 400MHz FSB where a 20% increase in FSB leads to an equivalent 20% increase in memory write performance.


EVEREST
Memory Write Performance @ 500MHz FSB

Each of the DDR3 boards continues scaling to 500MHz FSB with the expected 25% jump in memory write performance over 400MHz FSB. However, the DDR2-based 780i board stalled at just under 10GB/s signifying a rather serious problem with memory writes with this board. Whatever the problem was NVIDIA has obviously implemented the fix in 790i.


EVEREST
Memory Copy Performance @ 333MHz FSB

Memory copy benchmarks are unique in that they provide a great indication of just how well a memory controller balances the importance of read versus write requests. A chipset certainly cannot facilitate good copy speeds if read or write performance is low. The memory controller must first read the data from memory before it can write it back to memory (this is basis of a copy operation) and a bottleneck with either can bring everything to a crawl. Naturally, the DDR3 boards have an advantage in read performance at equivalent clock speeds and easily outclass the DDR2 boards.

To our surprise memory copy performance sometimes actually exceeded memory write speeds for the same FSB - in this case the 790i showed unexpected efficiency. A possible explanation for this phenomenon is the manner in which memory write requests are sometimes internally queued by the MCH until a lapse in memory read requests provides opportunity for a quick burst of write data to be sent across the memory bus, unimpeded by competing traffic.

In this respect, bandwidth as measured from the viewpoint of total memory throughput would be higher. Although the time to complete the pending write request might suffer, most writes are highly asynchronous - there would be little need for an instantaneous write operation unless an immediate read request depended on data stored by the same write to memory. In that case the controller could recognize this condition and simply read the data from the "cache line" without even touching main memory. You could almost argue that the MCH provided the functionality indicative of a highly specialized L3 cache in this particular situation.


EVEREST
Memory Copy Performance @ 400MHz FSB

We see here the roles reversed with the X48 Express chipset showing better memory copy performance than both 790i-based boards.


EVEREST
Memory Copy Performance @ 500MHz FSB

The Intel X48 Express wins again at 500MHz FSB, an oddity considering the commanding lead held by 790i when it comes to memory read performance at this system bus speed. We are tempted to give Intel's X48 the nod for the win, seeing as how it either wins or ties 790i in three out of four tests (memory access latency, memory write performance, and memory copy performance).

Memory Access Latency and Read Performance Complete BIOS Tuning Guide - "Extreme Tweaker"
Comments Locked

23 Comments

View All Comments

  • seamusmc - Friday, April 11, 2008 - link

    For folks considering this board, I strongly recommend visiting xstremesystems.org's forums.

    Several people are experiencing data/OS corruption when performing any FSB overclocking. (Brings back memories of the early days of the 680i.)
  • nomagic - Friday, April 11, 2008 - link

    LGA775 Core2 Duo/Extreme/Quad, Pentium EE, Pentium D, Pentium including next-generation 45nm CPU support

    Which would include Nehalem, I suppose? Should I also assume that a BIOS update would be required for Nahalem support? Is it possible that a custom board like this might have trouble supporting Nehalem when the times comes?
  • TemjinGold - Friday, April 11, 2008 - link

    No. NOTHING out right now can support Nehalem as that's a completely different socket (different pin count too).

Log in

Don't have an account? Sign up now