Asus Z490 - Bios Done Right.
Here is an overclocking guide for the Z490 Maximus 12 series.
This was done on a 12 Extreme, but should apply throughout the series.
This is based on a 10900k.
Bios used: 0508.
A big thank you to the great Shamino at Asus for supplying the test system used for review.
Easy mode for people who just want to play video games fast or get to work
Use all auto settings (all intel defaults-->load optimized defaults or after clear CMOS) to use system within Intel spec settings.
You can check your "SP" or chip quality rating in your BIOS.
Average chip is 63--most end users will get around this.
World record clocking LN2 SP chip is 117.
Boot windows and run a simple load like Cinebench R20.
Then go back to BIOS and set core Ratio to AI Optimized.
Protip: the Exact settings AI Optimized sets or recommends to you can be found
in the "AI Features" page
(You can enable XMP as needed for your RAM).
Unfortunately I cannot help with memory overclocking, guys.
Manual control the fast way:
Enable XMP, and just set your CPU multiplier. No need to change anything else.
The other auto settings should work well, 4.8 to 5.1 ghz without needing to tweak.
Gamers should get easy 5.0 ghz on all cores. No problem.
Low end air cooler: 4.8 ghz
High end air cooler: 4.9 to 5 ghz
Good water AIO: 5 ghz-5.2 ghz, depending on chip quality
Custom loops, chilled water, delids: 5.2 ghz easy+, depending on quality
Extreme Torture stress tests: 4.8 ghz air, 5 ghz Water.
On all auto settings, your CPU will utilize thermal velocity boost component of turbo boost 3.0
allowing 4.9 ghz on all cores if CPU temp <=70C. Otherwise 4.8 ghz via Turbo boost 2.0. On light loads, the two best cores will run up to 5.3 ghz at <70C, otherwise 5.1 ghz for light loads.
Turbo Boost 3.0 behavior:
1) There are only two favored cores defaulted for x53 ratio. They can be viewed in
BIOS in CPU configuration or with newest CPUZ, under tools->clocks (in red).
2) Windows 10 ver 1909 or newer is required to prioritze favored cores.
3) You can only boost to x53 for light loads on TB 3.0 if:
a) no more than 2 cores are loaded.
b) the cores being used as the favored cores.
On all auto settings, Intel power limits and power limit time (TAU) will be respected. 250 watts "short term" CPU package power for Power limit 2, 125W long term PL for power limit 1.
Taking manual control:
Setting all core multipliers manually will max your power limits and remove PL restrictions and multiplier restrictions from TVB.
Want to control your cpu voltage with fixed vcore without risk of overvoltage?
Bios will test your cooler. You can boot to windows a few times, run some regular programs then reboot and it will recalibrate the cooler.
Then just look at the prediction value. For most users, you want the "Non AVX" voltage. This is the voltage you set *IN THE BIOS*. And is calibrated for Level 4 Loadline Calibration. Set your manual vcore control closest to the predicted value, up to 5mv higher (example: if 1.172v predicted, set 1.175v, not 1.170v).
And that's all you need to do. You should be stable in 99% of applications, even normal stress tests, including realistic AVX stress tests (Realbench 2.56, Cinebench R20, Prime95 AVX disabled small FFT, AIDA64 Stress FPU). Prime95 small FFT with AVX or FMA3, Y-cruncher AVX2, LinX 0.9.6, Linpack Extreme are not important for 99% of users! Please ignore it for your own sanity. It really is not important. If you care about that anyway you can read advanced options below.
Advanced stuff for those who like reading (or who enjoy Buildzoid's oscilloscope videos!)
The Asus Bios is universally considered to be the milepost for how to design a UEFI Bios, and while this is my first Asus board since the legendary P5W series
Compared to Z390, Voltages are toned down. No more getting 1.35v IO/SA on XMP 3200 RAM. All auto settings (bios defaults) now use 100% spec Intel power limits and voltages, while some competitors seem to be back to breaking the rules to make their boards look better, which was happening all over with Z390.
The most important new feature Asus has included with Z490 is their voltage tuning.
I've tested this extensively on a 10900k sample at 4.8ghz-5 ghz on all cores, and Asus tuning for standard users is literally 100% accurate.
Asus has two main tunings: Non AVX and AVX. These are tuned for Loadline Calibration level 4 (L4). The calibrations work up to L6, but become more inaccurate at L6 and you should tune to your specific system. Higher levels of LLC have worse transient response, so it's impossible to get full accuracy at all LLC levels. I have used L4 up to 5.2 ghz prediction (only Cinebench R20 tested @ 5.2 all cores).
An example of what a high LLC does to your transient response can be seen on these Z390 scope captures using a 11 Gene:https://elmorlabs.com/index.php/2019...ne-visualized/
As Buildzoid noted, it is the absolute minimum voltage that determines stability, not your average RMS. With the improvements to Z490 VRM, using a level 4 LLC keeps your Vmins very close to the voltage transient dips.
Non AVX is based on Prime95 29.8 build 6 small FFT with AVX disabled, and based on your cooling solution, sets a minimum voltage that is needed to maintain full stability. Normal users please focus on this.
At full load, this is called an absolute "vMin", or a minimum load voltage floor that is needed to process SSE2 instructions without errors. If full load die-sense vcore for any other app drops below this point seen in Prime95, based on the predicted point you set in BIOS, you may have stability issues.
Note that AVX instructions are an extension of SSE2 instructions, and this is why SSE2 stability is important. Yes, AVX instructions use more current and draw more heat, but contrary to what most people think, the "minimum" voltage floor is almost identical. What changes the floor is heat. Vdroop does not change the floor--it simply changes the starting (Bios set) voltage needed to compensate for it.
In my own tests (assuming your hyperthreading related "Auxiliary" voltages are set correctly--VCCIO and VCCSA), the Non-AVX Bios set prediction values will give the average user FULL stability in both non AVX programs and in realistic AVX Stress tests-including Realbench 2.56, Cinebench R20, AIDA64 "Stress FPU", and Battlefield 5.
I've found that Prime95 small FFT with AVX disabled, Realbench 2.56, CB R20 and AIDA64 "Stress FPU" are all very close to the same current load and require about the same voltages overall.
The "Die sense" full load vcore reported vmin (based on prime95 small FFT AVX disabled) is the target point. If your AVX workloads remain at or above this Vmin, you should be stable. What you do not want is for your AVX workload to drop below this Vmin at full load.
The AVX bios voltage requirement is based on Prime95 small FFT with AVX. I found these not as accurate on L4 as the AVX disabled predictions, because the die-sense load voltage for AVX enabled may drop lower than the Vmin point of prime95 small FFT with AVX disabled at the prediction points. That can cause instability, so if that happens on your chip, increase bios voltage a bit until the load voltage is better than the prime AVX disabled load voltage. You can use HWinfo64's WHEA sensors log to check for CPU Cache L0 errors.
Also please keep in mind that the heat output of AVX enabled is going to also be MUCH higher than AVX disabled, which will also require an even higher Vmin. Example: If your chip is stable at load 1.05v @ 4.7 ghz in AVX disabled small FFT Prime95, it's NOT going to be just as stable at the same 1.05v load 4.7 ghz AVX enabled prime95, because your temps will be about 10-15C higher. You need to compensate for that.
Gamers and content creators should pay attention to the Non AVX predictions. They are that good.
Now I'm going to say this directly: PRIME95 AVX SMALL FFT STABILITY IS NOT IMPORTANT ON THIS PLATFORM! The AVX disabled prediction is good enough for regular AVX use!
Unless you are doing medical or scientific /number crunching work that requires these instructions, don't worry about AVX small FFT. Seriously. Passing Prime95 AVX small FFT, FMA3 small FFT, LinX 0.9.6 35000 sample size, Linpack Extreme 1.1.2, and putting 250 amps into your CPU is cool and all and it feels good if you pass it, but seriously it's NOT important! Heat output on 10 cores and the higher vdroop and current draw in these worst-case torture tests are NOT based on realistic usage situations, so there's NO need for anyone to say "If it's not AVX small FFT stable it's not stable." This applies even more when you exceed 4.8 ghz on all cores.
Another thing: Stop complaining about VRM temps! Cooler temps are always nice to have, but VRM's are designed to run hot and can operate to their rated temps. A VRM isn't a CPU. A VRM isn't suddenly going to throw math calculations or make your +12v drop to 10v at 85C. 60-70C is fine. This is fine. You can always use the fan to cool them more. Capacitors care about temps at 85C max. A VRM can run at 100C without causing crashes. So there's no need to say board X is worse than Y because X VRM's reached 75C while Y's reached 55C so Y is better--not true. That will not affect performance.
Personal test results: Here are some of my own results from testing to demonstrate the accuracy of "Non AVX Prediction" at LLC4:
Vmins: Fixed Vcore test: 4.7 ghz: low vcore:
1.150v bios set, LLC4-->stable Apex Legends, Minecraft loading, AIDA64 "Stress FPU" (1.039v load! AIDA FPU), Prime95 AVX disabled small FFT stable
VMIN: 1.145v bios set, 1.012v load, Realbench 2.56 4 hours stable, 62C max, AIDA64: 1.012v load. 1 hour 64C max. Prime95 small FFT AVX disabled stable (1.012v load). 1000 khz VRM switching frequency seems to help Minecraft loading screen vmin very slightly. (Minecraft is a special case as it puts a 100% load on all cores when loading. It also seems to expose a 'bug' in the skylake core causing an Internal Parity Error randomly at a Vmin higher than expected. This bug was found during Apex Legends testing and debugging by Respawn's programmer Oriostorm, This causes a "Parity Error" rather than the more expected "L0 cache error" from too low vcore.
4.8ghz, 1.215v L4 LLC, AIDA64 stress FPU stable (1.066v load AIDA64 FPU stable), Minecraft loading stable, Prime 95 AVX enabled stable.
Bios set test: 1.180v LLC4: AIDA64 Stress FPU: 68C, 1.048v load
Realbench 2.56, 66C, 1.048v load, Minecraft Java: random Internal Parity Errors loading
Minecraft Java VMIN: 1.190v L4, 1.066v load, 60C max, 22 loads, No Internal Parity Errors over 22 consecutive main menu loads.
Absolute Vmin bios prediction: 1.175v, VRM 1000 khz-->seems to help minecraft.
4.9ghz, 1.225v L4 LLC, AIDA64, minecraft java load (1.083v load AIDA64 FPU, 145 amps, 72C, 1 hour test (Arctic Freezer II 360, ambient 74F)
5 ghz/4.7 cache @ 1000 khz
LLC4 test: 1.285v LLC4-Vmin SSE2, Normal AVX, Minecraft load loops, Prime95 SSE2, etc: 1.128v load. Minecraft Java loading screen test 40 loops @ LLC6, 500 khz (100% CPU, CPU Internal Parity Error test):
Higher LLC test: 1.235v bios set LLC6, VCCIO: 1.05v, VCCSA 1.10v. Load voltage vmin: 1.153v
Hyperthreading seems to be very dependent on IO/System agent voltages, and very erratic stabilty can happen when you are very close to the voltage Vmin. To check if L3 cache/IMC (Via VCCIO/VCCSA, which are signal rails, both related to the memory controller) is hurting stability, use Prime95 AVX disabled in-place fixed FFT 112k-112k and look for HWinfo64 WHEA CPU Cache L0 errors within 10mv of your Vmin or for random programs crashing during the 112k test. 112K in-place fixed FFT is a strange case. It actually hits the system RAM and caches hard, so it can determine if your IMC auxiliaries are set properly.
When testing at your vmin, if your VCCIO/VCCSA is too low, you may get the following:
1) WHEA CPU Cache L0 error in HWinfo64 sensors.
2) System Service Exception (or IRQL) BSOD
3) Random crashed prime95 threads.
4) Your Video driver settings crashing randomly during the stress test (Radeonsettings has stopped working).
There seems to be about a 10mv-20mv range where a too high IO/SA (or too low) will cause random issues during a 112K-112K in place AVX disabled Prime95 stress test, or during Realbench 2.56 / AIDA64 Stress FPU, unless you increase CPU Vcore enough.
If your IO and SA are set properly, if your Vmin is too low, AIDA64 "Stress FPU" should report "instability detected" instead of you getting a BSOD or your video card driver crashing
I found that 1.05v VCCIO and 1.10v VCCSA seems to be the best point for me. Your mileage will vary and it depends on your RAM timings and memory speeds!
If you are unstable, you can also just increase CPU Voltage. Also note that higher XMP speeds also will require a higher IO/SA. This is the reason why people have found that they need a higher CPU Vcore when overclocking their RAM. Sometimes a higher IO/SA at 4000 mhz RAM speeds will let you reduce vcore slightly.
Some random AVX power virus tests (seriously don't focus on small FFT AVX).
Prime95 AVX1 15K: 1.250v LLC6, VCCIO: 1.05v, VCCSA: 1.10v (load voltage min: 1.128v).
Prime95 AVX2 (FMA3) 15K: 1.270v LLC6, VCCIO: 1.05v, VCCSA: 1.10v (load voltage min: 1.137v)
5.1 ghz: Prime95 AVX1: 1.320v LLC6--100C (FMA3 is impossible--temps).
5.2 ghz: Cinebench, gaming: 1.380v LLC4 (prediction)--1.199v load--passed CB R20. I did not do much testing at all here. 1.350v LLC6 also passed.
5.3 ghz test: : Minecraft loading, Battlefield 5 fully stable @ 1.380v LLC7, Stress testing is impossible (temps--100% in seconds then hard lock, e.g. Cinebench R20).
Battlefield 5 reached the 80's.
I used a high LLC here because of lack of prediction points at 5.3 ghz (too few samples) and vdroop would be much too high, so I wanted a lower BIOS voltage at the cost of bad transients.
An issue with offset voltage/adaptive when using a high AC Loadline, and why ACLL/DCLL 0.01 mOhms is very good.
Random tech rambling.
5.3 ghz+ Offset voltage +5mv + SVID Behavior: Typical (AC/DC Loadline=0.6 mOhms)+ Loadline Calibration: Intel default (1.1 mOhms = LLC3): seemed to be VERY unreliable and unpredictable depending on test: Idle voltage was 1.420v, however Random Internal parity errors loading Minecraft. However Vcore response was VERY smooth and evenly controlled when doing any full core load like Cinebench R20 (1.320v load) with no oscillations. But loading minecraft or Battlefield 5 caused erratic voltage swings from 1.305v(!) to 1.480v(!), which made vmin randomly too low. This is the same issue I encountered on Z390 when trying to use AC Loadline to control load voltages at a high overclock. It seems that ACLL can boost the output voltage reliably using this formula:
Vcore=vCPU + (ACLL * IOUT) - (LLC * IOUT) + vOffset
However with mixed AVX/non AVX loads that are NOT on all cores loaded, it seems like ACLL doesn't raise the output voltage at the correct time, which causes too much vdroop, and at other times raises it during a low load situation, causing too much vcore. This is not a bios bug, but rather an issue with mixed loads with high transients and AC Loadline responding to it, as I encountered on the Z390 Aorus Master when trying to use Offset mode (Auto mode=offset + 0mv) with AC Loadline 1.6 mOhms, LLC: Standard (1.6 mOhms=Intel spec) at 5.2 ghz. Example: 1.32v during Cinebench R20 (nice and even VR VOUT), but Battlefield 5 ranging from 1.28v (= BSOD!) to 1.46v
The only way to avoid an issue like this is to set ACLL to 0.01 mOhms to limit how much it can boost the output voltage, but then you need to use a higher Loadline calibration. (remember: on offset mode, the HIGHER you set the AC Loadline value, the LOWER Level you must set for Loadline calibration (low levels of LLC=higher mOhms of resistance, so you should try to keep ACLL close to LLC (VRM Loadline).
But if you're going to use offset mode with ACLL 0.01 mOhms, you're better off using fixed vcore or adaptive voltage anyway. The only advantage of offset mode with ACLL=0.01 mOhms, compared to fixed vcore (let's say you are using LLC: L6 in both) is the ability to downvolt while idle to avoid high idle voltages, but there is one other advantage: offset mode with ACLL 0.01 mOhms allows you to take advantage of Thermal Velocity Boost to raise the vCPU as temps increase, but if you need to use a higher Loadline calibration, you get a transient response penalty compared to a steeper LLC.
As a gamer, and you hear this often, it's commonly recommended to disable all c-states and power saving to maximize stability. Having a constant clock and steady voltage states with c-states disabled is often recommended by many experienced people, including Mr Fox on notebookreview forums and LN2'ers and so on.
Having the new VF curve feature can help with low load instability issues when using c-states in offset or adaptive modes. Using a fixed offset applies the offset to all voltage points at each frequency step. You can use the VF Curve to tune this.
(end of part 1)