Overclocking workflow
It’s time to lay out some overclocking methodology. Our approach to overclocking isolates portions of the system by using stress tests that focus on specific areas. Once the system is stable in all tests, we proceed to test all areas simultaneously. By doing things this way we avoid confusion, as isolating portions of the system while applying an overclock gives us fewer variables to debug when faced with instability.
Don’t worry if the references to adjustments don’t make sense right now. We’ll provide you with some screenshots of what to adjust on the following page.
- Before you overclock the system, run a stress test at stock settings – a one-hour test should suffice. Check that CPU temps under full load have sufficient headroom for overclocking, and that the system is stable. Keep a close eye on temps once the CPU is under full load for a few minutes, just to make sure it isn’t throttling its frequency due to over-temperature (typically, 95 Celsius). CPU-Z and third-party tools such as AIDA are useful for monitoring frequency and temperatures. If there are any problems with temperatures or stability, do not proceed until you’ve found and fixed the issue.
- Assuming everything is okay, overclock the CPU cores first and establish stability before configuring the memory or cache ratios. We recommend using Adaptive voltage mode rather than Manual or Offset mode. Choose a CPU-intensive stress test. We prefer using a looped 1080p Handbrake encode (1~4 hours), as that’s the toughest load we’ll place on our system. Check CPU core temps once again to gauge how much headroom the cooling has for further overclocking. If the CPU is stable, increase the processor core ratios one step at a time while monitoring temps and noting the amount of Vcore required for stability.
- If you keep notes on the Vcore required for each multiplier ratio increase, you will find a certain point where the required Vcore increases exponentially. If your target usage scenario involves heavy multi-threaded workloads, then it is wise to set the overclock frequency at a point before there is an exponential rise in the required voltage for stability. Setting the overclock using this method results in lower power consumption and is kinder to the CPU from a longevity point of view.The absolute max temperature we’d like to see during our usage case would be 80 Celsius during a Handbrake encode, which provides us with some headroom for the few summer days we experience here in the UK. The gist is to ensure temperatures under full load have sufficient margin to account for ambient variance due to weather or sources of heat within a PC case – catering for such variance helps avoid throttling.
- Once CPU core stability is established, configure XMP for the memory modules – if they support XMP – and run a memory-intensive stress test to ensure the system is stable. (Recommended stress tests are listed later in this guide.) If stability cannot be established with XMP engaged, try reducing the CPU core clock to debug where the issue lies. Keep Vcore at the same value when doing this, just to remove CPU core instability from the equation. If the system becomes stable at a lower operating frequency, then you may need to tune Vcore, System Agent (VCCSA), and VCCIO voltages. If none of these help stability, the memory timings or DRAM voltage may need adjustment.
- If the system is stable, you may wish to experiment with Uncore overclocking. 500% of coverage in the HCI Memtest is a good test for the Uncore, as is AIDA64’s Cache test. Keep a close eye on temps to ensure they do not exceed 80 Celsius.
- If you’ve made it this far, consider optimizing the overclock by using the ASUS temperature control features and AVX offset for light and heavy workloads.
Preferred Stress Tests
Here are our preferred choices for stress testing the Kaby Lake architecture:
- ROG Realbench for all round application stability. Use the stress test option with the correct amount of system memory assigned. Run for 2~8 hours. The stress test uses a combination of Handbrake, Luxmark and Winrar to test multiple areas of the system. It works very well as a stress test for this platform.
- Google Stressapp Test via Linux Mint (or another compatible Linux disti) is the best memory stress test available. Google use this stress test to evaluate memory stability of their servers – nothing more needs to be said about how valid that makes this as a stress test tool.Install Linux Mint from here: http://www.linuxmint.com/download.php
Install the Google Stress App test from here: http://community.linuxmint.com/software/view/stressapptest
Once installed, open “Terminal” and type the following:stressapptest -W -s 3600
This will run stressapp for one hour. The test will log any errors as it runs. Stressapp is more stringent than Memtest for DOS, HCI Memtest for Windows, and any other memory test we have used for isolating the memory bus.
- HCI Memtest– A good combined memory and Uncore stability test. Run as many instances as there are logical CPU cores, assign 90% of the available memory, and run until 500% coverage is completed (longer if preferred).
- AIDA64 – Includes a variety of stress test options to load various parts of the system. We recommend the Cache test for evaluating stability of the Uncore. Run for 2~8 hours.