Data Corruption - not Political Corruption - with NVIDIA’s Latest Boards

Our performance board roundups ended up delayed for a variety of reasons, but we will be back on track next week. Every conceivable problem has hit us from shoddy BIOS releases to repeated problems getting Crysis to benchmark correctly under 64-bit Vista. We are still not sure about the latter problem, as one image works and another does not on identical hardware and software setups. We finally got to the point of being able to benchmark, but it is not a process we would wish upon our worst enemies.

However, none of that compares to the data corruption problems we are seeing intermittently on the 790i and 780i platforms. We honestly thought NVIDIA had solved these problems back in 2006 on the 680i platform. Since the MCP has not changed, it is disconcerting to us that this problem seems to be rearing its ugly head again. This time, the data corruption problems appear contained to memory overclocking, especially on the 790i boards. We are not talking massive overclocks here, but apparently hitting the right combination of FSB rates around 400 and memory speeds above DDR3-1600 seem to trigger our problems. Also, we have been able to reach higher DDR3 speeds with absolute stability on the 790i than on the X48 during extreme overclocking, so this problem is even more perplexing to us.

On the 780i boards, the magical combination is right above 400MHz FSB (1600 QDR) and memory unlinked anywhere from DDR2-900~1200. Our 780i problems have been minor for the most part, but the underlying problem is that after the systems recover from a BSOD, we typically have stability problems or gremlin behaviors until we reload the system. This same problem can occur on Intel or AMD chipset boards, but it is extremely rare in our experiences to date unless we absolutely pushed the memory beyond reasonable settings.


Back to the 790i boards; the data corruption problems have occurred more frequently as the boards (and their early BIOS revisions) seem more susceptible to faulty behavior when pushing the memory above DDR3-1600 with low latencies. We have not nailed downed exact settings at this point, as they tend to fluctuate between test sessions and boards. What we do know is that we are tired of constantly reloading our images after making minor changes to our settings.

It is possibly coincidence only, but over the past couple of months we have lost two WD Raptors, a couple of Samsung 500GB drives, and a WD 250GB drive while benchmarking the 790/780i boards. It may have just been time for these drives to meet their maker, as our particular samples have spent significant time running benchmarks almost 24/7 over the past year or so (it might not sound like a long time, but we totally abuse the drives to some degree when testing in this manner). We have certainly had hard drive failures when testing other chipsets, ranging from complete mechanical breakdowns to index tables being so corrupted that we could not fully recover the disk. It could just be bad luck on our part.

However, we think it goes deeper than that. After the first roundups this coming week, we plan to delve into it. The reason is that we have not had any data corruption problems testing our 650i/750i, GeForce 6100/6150, or GeForce 7050 boards, none of which utilize the MCP in the 680/780/790i boards.  Of course, this could be tied to the fact that we do not push the boards as hard, but knowing about the previous 680i problems makes us think the current BIOS code or Vista drivers need to be revised again.

Other problems

We share test notes on an almost continual basis with each other when testing boards. We thought some of the test notes from our upcoming roundup would be interesting. In all fairness to NVIDIA, we are including our X48 thoughts as we wrap up testing.

790i test notes:

a) CPU multiplier likes to changes at will, causing an inability to POST after changing BIOS options. (Problem is likely linked to bad NVIDIA base code).

b) Poor memory read performance above 475FSB unless you enable “P1” and “P2” which NVIDIA refuses to document operation of or provide information about.

c) EVGA/XFX (NVIDIA reference design) lacks support for tRFC tuning - high density DDR3 configurations often refuse to work unless the module SPDs are tuned from the manufacturer. (This makes them needlessly slow in low-density configurations.)

d) The chipset does not do a very good job of balancing read vs. write priorities with respect to memory access - copy scores lower than X38/X48.

e) Regardless of what NVIDIA says, we think PCI-E 2.0 (and 1.x) implementation is still better on Intel’s Express chipsets - give us SLI on Intel to prove it!!!

f) Possible problem with NVIDIA reference design: sustained overclocked operation at >~1.9V for VDIMM may cause critical failure of 790i (Ultra) SPP. This does not seem to affect ASUS S2E design and is the most critical issue facing the board; we need to verify before making recommendations.

g) Possible HDD corruption issues. (We lost the two 74GB WD Raptors so far…)

X48 test notes:

a) Chipset defaults to tRD values that are excessively loose and are not competitive with NVIDIA’s new 790i. The problem is most MB manufacturers do not allow this to be specifically tuned in the BIOS.

b) DMI interface (x4 PCI-E link) is sloooow….X38/X48 should have been paired with ICH10(R), which will be PCI-E 2.0 compliant on the link interface.

c) Haven’t found an Intel X48 board yet that will handle 8GB of DDR3 properly, even though this is a major bullet for chipset support - board or memory makers? (We need to test this on the Intel DX48BT2 that just arrived.)

d) Chipset runs HOT…might even be hotter than 790i. Intel should have shrunk this thing long ago!

That is it for now and we will have additional information in the first roundup. Now a take on Gigabyte.

Pop goes the MOSFET Walking the Plank with Gigabyte...
Comments Locked

81 Comments

View All Comments

  • JarredWalton - Sunday, April 6, 2008 - link

    Gary bypassed the copy editor, because I was busy being elsewhere. Consider him flogged. I'm now reading through it once and doing my best to vanquish any fragments, run-on sentences, or other miscellaneous typos. Any further comments on this matter should be directed to /dev/null. Thank you! ;-)

Log in

Don't have an account? Sign up now