About six weeks ago, I wrote and published two articles focusing on Athlon 64 overclocking, RAM testing, and the MSI K8N Neo2 (located here and here).  Collectively, these two pieces detailed the unusual instability I encountered above stock RAM speeds, the persistence of that instability across multiple brands and types of RAM, and the software disagreements I encountered when I ?asked? various programs what CPU multiplier was being used or what HTT link speed was set.  When ordered to use a half-multiplier, CPUID would report it properly (12.5x, 11.5x, 10.5x, etc).  Both Everest and MSI?s own CoreCell utility, however, reported a whole multiplier?12x when 12.5x was used, 11x if 11.5x was used, etc.  At the same time, both programs reported that the HTT clock was raised in order to ?fake? a half multiplier setting.  This, in turn, raised the memory clock and (we theorized) accounted for our RAM instability.

Traditional overclocking information on the Athlon 64 agrees that using a half multiplier rounds the memory divider?but states that the divider is rounded up (resulting in a lower memory clock than is actually predicted) not down.   Based the information reported by Everest and CoreCell (plus our conversations with AMD) I chose to believe the two utilities rather than conventional wisdom.  I further stated that I believed these instabilities and problems were either the result of an overeager manufacturer pushing its product to market, or unacceptably flawed BIOS engineering.  In order to determine whether the multipliers were rounding up or down, we sent the board to Michael Schuette of Lost Circuits, who agreed to perform oscilloscope tests.  The results of those tests are now in. 

According to Michael?s tests, the Athlon 64 + K8N Neo2 does round up when a half multiplier is used, and therefore runs the memory slower than is actually reported by most utilities.  Ironically, I was right to conclude that some utilities and software don?t report Athlon 64 settings correctly, but I chose the wrong set of utilities to trust.

I was wrong.  Not only were my previous findings incorrect, but the accusatory tone I used when presenting them was, in retrospect, overly harsh; I?ve apologized to MSI and I apologize to you readers for any confusion this situation may have caused.  I am leaving the previous two articles online in order to keep the details of this situation available, but have updated them accordingly. 

This story, however, isn?t quite over.  Michael?s tests did more than just debunk my theory; they discovered what was very likely the cause of our instability problems.  Curious?  Keep reading.

next >

---

• Back to Memory: VDIMM Testing Yields Answers. (1 of 4)
• What we Know and What We Don't (2 of 4)
• Inaccurate Software Reporting is Troubling. (3 of 4)
• Conclusion: (4 of 4)