As I mentioned in my last post a week ago, I had a hunch that the CPU was the source of all my locking issues in games. Originally, I suspected the clock was too high at ~100Mhz over stock, 2158 (166*13) @ 2262 (174*13). However, while researching Athlon XP’s on Wikipedia, I noticed that none of the Thoroughbred’s were set above 1.65 Volts, yet I had mine set to 1.70 Volts for years. I can’t recall now why I set the core voltage up .05v; it could have been that my original overclock demanded it for stability, there was a perceived need for increased voltage for better stability, or just my own ignorance at the time. It seems reasonable that the voltage is responsible partly, if not completely, for the instability. Increasing the voltage is often necessary to maintain higher clock rates, but they also add to the watts of thermal energy the CPU puts out (increasing the likelihood of overheating). It is also my speculation that increased voltage puts more demand on the capacitors that regulate the CPU power, potentially causing over-voltage failure, and it just so happens that I noticed a couple slightly burst capacitors recently (as seen in the photos below)–wondering if there’s a correlation.
-
- Burst Capacitors
-
- Burst Capacitors
Since I still couldn’t be sure if the problem was the core voltage or not, I was planning a battery of tests the day after Christmas to find a suitable CPU clock. I’d recently realized that my chipset and memory were both rated for a 200Mhz front-side bus, but I had been keeping it close to the CPU’s default of 166. Luckily, I got my 2700+ a couple months before AMD started locking the multiplier by default; therefore, I would be able to drop the multiplier and raise the FSB, roughly maintaining the CPU clock while increasing the memory bandwidth. I was hoping this strategy would allow me to lower the CPU clock as much as necessary and make up the performance with increased bandwidth. The only unknown factor was possible increased CPU latency due to the lower multiplier.
I spent five or more hours running through my test battery, which consisted of Sandra 2005 CPU Arithmetic, CPU Multimedia, and Memory Bandwidth tests; some or all of 3DMark 2005’s game and CPU tests; and the Half-Life 2 benchmark (which apparently is only available through Counter-Strike: Source now). 3DMark’s GPU tests were understandably unhelpful, except later on when I discovered that the Firefly test was extremely memory-intensive. As I tried to find the maximum stable FSB clock, this test proved most helpful. Half-Life 2 showed little responsiveness to the increased memory bandwidth and was only slightly more affected by the CPU clock, even when the video card wasn’t the bottleneck. Sandra’s tests were the most consistently telling of raw performance. As expected, memory bandwidth scaled quite linearly with increased FSB clock. And although the multimedia benchmark was mostly useless, the arithmetic benchmark showed slight performance degradation due to a lower CPU multiplier; but in the end, it was much more affected by CPU clock speed.
T
he benchmarking sequence I took was to decrease the multiplier by .5 each time and then bring the FSB up until the CPU clock was about 2200Mhz. However, when I reached 11*200, I noticed that HL2 and the 3DMark were exhibiting strange crashing. I tried lowering the FSB until I brought these crashes under control (~190Mhz). However, at 11.5*190, the CPU clock was too low, so I raised the multiplier to 12 and set the FSB to 186Mhz for a comfortable 2232Mhz. This has proved to be very stable over the last week, so my next move is to bump up the FSB to 188, which would bring the CPU clock to nearly the same as it has been for the last few years and ultimately show that the core voltage was the problem all along. All these tests were run with a core voltage of 1.65v (stock).
The only problem with using a multiplier of 12 instead of 13, is that most programs identify my CPU as a 2400+ instead of 2700+. But really, it’s more like a 3200+ in terms of performance.
I’ve been enjoying my new stability by playing through Half-Life 2 Episodes 1 and 2 in the last week. Yes, episode 2 was that good that I wanted to play it again. It was much easier to appreciate the game without random locking and with commentaries turned on. I was surprised how often Valve mentioned changing the game in response to the actions of playtesters. This seems like something more developers should pay better attention to.
