Skip to main content

System Builder Marathon Q3 2014: Budget Gaming PC

The Trials (And Tribulations) Of Overclocking

Overclocking with the H81M-P33 is fairly straightforward. The shipping UEFI, version 1.4, had no problem booting up and recognizing the Pentium G3258. I grabbed the latest BIOS file directly from MSI and used the built-in MFlash utility to update to v.1.7, which also updates the Intel Management Engine. After a couple of reboots, the CPU multiplier was adjustable from 8 to 80 using the number pad’s '+' and '–' keys. For fun, I set the ratio to 40x with automatic voltages and it fired up at 4.0 GHz at 1.200 V. The configuration was stable under Prime95, so if I didn't want to push any further, the overclock would have been that easy.

I already knew some enthusiasts were having a hard time getting the G3258 beyond 4.0 GHz with the stock cooler, while others lucked-out with chips able to reach 4.5 GHz. There are no guarantees in overclocking, but I was quietly hoping for at least 4.2 GHz at 1.2 V. That turned out to be overly optimistic; this CPU needed lots of voltage to pass 4.1 GHz.

Determined to reach 4.2 GHz, I jumped to 1.275 V, which crashed within minutes under load. At 1.29 V, the overclock lasted over 20 minutes in Prime95, but temperatures were peaking at 80 degrees. That's where I quit, knowing I was already above the voltage level I'd use for testing. So, I started looking for the lowest stable voltage at 4.1 GHz.

The highest RAM frequency available with the Pentium installed was 1400 MT/s, but I left it at 1333 MT/s and fought for lower latencies. Increased to 1.545 V, numerous passes of MemTest 86+ ran error-free at 7-7-7-21 1T.

As mentioned, Sapphire’s Dual-X R9 270 has a slightly overclocked core, reaching up to 945 MHz out of the box, while its 2 GB of GDDR5 memory operates at a reference 1400 MHz. To start, I fired up the latest version (4.8.6) of Sapphire’s Trixx tweaking utility.

The core topped out at 1030 MHz using its default voltage. Reaching stability at R9 270X speeds of 1050 MHz required a bump to 1.225 V. I then set the graphics fan to 100%, gauging maximum frequency at a pegged 1.300 V, finally giving up stability when the GPU hit 1070 MHz. Given such modest gains, I dropped back to 1050 MHz.

Next, I started bumping up the GDDR5, eventually reaching a stable 1510 MHz. I dialed this back down to 1500 MHz (6000 MT/s), and put the final overclock through more than an hour of real-world gaming without issues.

Unfortunately, the story doesn’t end there. After completing Far Cry 3’s most demanding benchmark runs, I dropped to 1280x720 and the system blue-screened. Minor voltage bumps and clock reductions didn’t solve the issue. I had to individually re-test the CPU, RAM, and graphics overclocks over again, encountering no problem. As soon as I put them back together, the random reboots returned under light gaming loads.

Based on the event ID, I suspected the graphics card wasn’t getting sufficient voltage. But was it the power supply, motherboard, the single 6-pin power lead, dynamic voltage control, or some combination? I wanted to force a constant voltage under 3D loads, but had already discovered that the Trixx utility shut down any time I touched the settings tab. So I tried MSI AfterBurner. But it was unable to adjust or monitor the voltage. While I hate admitting defeat, I was out of time and had to move on. I dropped back to stock graphics clock rates for their guaranteed stability, and counted on Intel's Pentium for the largest gains. Then I ran all of my single-screen tests before calling it a night.

The next morning, I wanted to try one more idea before hooking up my triple-monitor setup. Considering that I reverted back to an older version of CPU-Z to properly read the Pentium’s voltage, how about trying an older version of Trixx? Lo and behold, build 4.8.2 gave me a functioning settings tab, which opened up the option to Force Constant Voltage and Disable ULPS (Ultra-Low Power State). ULPS was already disabled, but forcing a constant voltage solved the problem. I could now happily run lighter-load tests without fail.