cancel
Showing results for 
Search instead for 
Did you mean: 

Maximus 13 and Rocket Lake: The Rules have Changed.

Falkentyne
Level 12
Thanks to Asus and the wizard Shamino for allowing me to test drive their Maximus 13 Extreme and RKL 11900k sample for this user guide.

Welcome to a strange time in PC land. Where scalpers, miners, scammers and the pandemic have changed a landscape that was once standard fare and far too familiar. Intel throwing on Moar Corez while AMD's Lisa Su just laughs and goes "IPC, baby", while giving us even moar corez! But Intel knew things needed a change and with excellent cooperation with Asus, have finally moved on past an aging architecture that was already past its breaking point, something gamers are now beginning to see with gems like Minecraft! And Asus, with its Z590 Maximus lineup, has once again set the tone for everyone else to follow, with a massively improved VRM (International Rectifier has finally been switched out for Intersil, improving vdroop and transient response), more phases, world record memory overclocking with DJR and a new emphasis on something called stability.

But first let's discuss what was happening with Skylake.

While original Skylake had a rough start (microcode and firmware bugs galore and rather poor overclocking), Intel improved things with Kaby Lake, finally bringing 5 ghz overclocks back to realism, similar to what we got during the Sandy Bridge era. And soon after, making more than 4 cores mainstream, as before the only way to get more than 4 cores were in their HEDT lineup, and the "Enthusiast" platform previously, the X58, with the 6 core Nehalem processors. The 8700k was well welcomed, but there was a dark horse looming that no one seemed to notice or care about at the time--the ringbus/interconnect problem.

Not long after the release of the moar corez 9900k, the first 8 core consumer chip which led to an arms race of cores, came the release of a game called Apex Legends, just a few months later. And unknown to almost everyone at the time, this game showed that the ringbus extension to more and more threads was completely broken. The result: An error called the "Internal Parity Error", which related to the cache/core subsystem and its internal buffers. This problem was massive, generating a gigantic megathread "crash thread" over on the EA forums with people's prime / ycruncher stable systems just randomly going back to the desktop, and a few people who noticed that WHEA Errors were being generated. The WHEA was the crash actually being prevented (corrected hardware error).

To get more of a clue about this error, we have to dig deeper. While many people were just pumping more vcore into their systems to try to bypass the Parity Error and the random crashes, I actually tried *lowering* the voltage even more, just to see what would happen in Apex. Sure enough, this was enough to occasionally BSOD the game, but more importantly, I was able to generate a new error alongside the parity errors:

"Translation Lookaside Buffer Error" (TLB).
"What is a TLB? In a very basic definition, a Translation lookaside-buffer (TLB) is a cache that memory management hardware uses to improve virtual address translation speed. All current desktop, laptop, and server processors include one or more TLBs in the memory management hardware, and it is nearly always present in any hardware that utilizes paged or segmented virtual memory.

By default, a TLB miss whether caused by hardware and/or software complications is not fatal (if the virtual address is not stored in the TLB, it's simply computed and found manually from other source data), but we're crashing on a TLB failure, this implies that the CPU determined there was corruption or a hardware error in date, therefore notified Windows that an unrecoverable hardware error has occurred."

What this shows is that Apex Legends is causing the CPU's to function in a very unstable way, and since some users with completely stock systems were getting Parity Errors and crashing in Apex, this was a MAJOR problem.

Respawn tried to look into this, and thanks to the programmer Oriostorm's efforts, he determined that these errors were a *flaw* in the Skylake processors. Specifically, he noticed that, due to some combination of code on the King's Canyon map, under certain rare (considering just how many instructions are processed every second!) conditions, the processor will attempt to read or write to memory it has "no permission to access". This causes an exception error (read, write or execute) and the game to naturally crash. The parity error was simply this error being caught and corrected in time. The fact that reducing vcore even more would lead to a TLB error showed that there was a very low level issue with multithreading and the ringbus happening here.

Oriostorm decided to change the code path to attempt to prevent the circumstances which would cause this error (I believe the old system was "old_gather_props") or something. The new code path massively improved stability and bought Apex in line with other normal games of the time, and no longer ruining people's daily overclocks.

Notes in the May 2019 patch gave me and some other users credit for helping Respawn improve stability of their game.

https://www.ea.com/games/apex-legends/news/performance-update-may-2019

"[PC ONLY] CRASHES SPECIFIC TO INTEL CPUs

We investigated the crash reports from many people who were crashing frequently and found that Intel CPUs sometimes were not executing the instructions properly in one particular function. A common example was an instruction that only reads a register crashed on writing to invalid memory. With the help of many forum users, we found that lowering the clock speed always fixed the crashes, even if the CPU wasn't overclocked or overheating. Thanks everyone, with a big shout out to Falkentyne, TEZZ0FIN0, JorPorCorTTV, and MrDakk!

This has been by far the most commonly reported PC crash over the last month or so and we’ve notified Intel about the issue. In the meantime, we’ve put a workaround in this patch to avoid the crashing at your original clock speeds just by changing the instructions used by that one function."

But this was only the beginning. But until Apex Legends, no game had brought out the multi-score "Skylake threading" problem like this, and even though no one knew anything about this at the time, this "Internal parity error" crash and Apex needing a new code path to bypass the threading conditions was the result of the Skylake interconnect system being stretched to more cores, and helps explain the even bigger latency penalty on CML cores (relative to core position on die).

Minecraft was a java game that had been out for many years now, and at the time, Minecraft crashing was usually just people's windows being corrupted or drivers out of date. Minecraft generating "Internal" errors was completely unheard of at the time. Parity Errors simply didn't occur unnaturally on 4C/8T processors since the architecture hadn't been extended to its breaking point. If you actually got a parity error on 4C/8T, you were truly unstable and were probably waiting for a L0 or a BSOD. Even the 6C/12T gen was mostly overlooked since it was so brief. When the 9900k hit, however, this is when more users started noticing Parity Errors being generated by MC, although no one had a clue what was going on.

What broke the camel's back was the 10C/20T CML.

First, OC'ers noticed that cache/RAM latency went up (as mentioned above). This was obviously forced to happen, but users were rewarded with yeet RAM overclocks from a stronger IMC, and 5.3-5.4 all core overclocks on good chips, which kept CML competitive with AMD's offerings, as AMD simply couldn't touch Intel on memory overclocking. But as thread count went up, the problems causing Parity Errors became more obvious, as players started encountering Minecraft errors in droves, some people even on stock clocks, and some AAA Games (like RDR2) were also generating Internal WHEA errors. The L0 error was already well known; errors on virtualized instruction registers in the L0 register store, which only happened on hyperthreading enabled processors, which was already the major issue with skylake stability. You could push high overclocks and get random L0's which were very difficult to stabilize, depending on the instruction set used, but enough vcore would fix it. But the parity error showing up on systems that passed stress tests was the sign that Skylake, never meant to go up to so many cores, needed to die. And with newer RTX/DLSS games now starting to generate Parity Errors on daily stable systems, something needed to be done.

Enter Rocket Lake.

While Rocket Lake is prep for Intel's true next gen platform, Alder Lake and DDR5, Intel needed to prepare this platform for maturity, while moving on from Skylake and all its bugs. While ADL is rumored to have two IMC's, the backport of Cypress Cove to 14nm, with only one IMC and the Gear changes, hurt RKL considerably. But this is a necessary evil because Skylake HAD to die. And the IPC increases (~19%) are real and will only keep getting better on future gens. But with people breaking NDA, and releasing benchmarks with pre-beta Bioses and broken memory overclocking, showing off terrible bandwidth results (NDA's exist for a REASON, people!), every single person overlooked something.

Stability.

The Death of Skylake also meant the death of Skylake bugs.

1) CPU Cache L0 errors are now a thing of the past. No more random L0's thinking you're stable and only partially stable with BSOD's that look like RAM errors (System Service Exception, IRQL_NOT_LESS OR_EQUAL, etc). You just BSOD now, with the well known "Clock Watchdog Timeout", or in other words "I'm not stable, chump, try again". There's no more "middle road". You're either stable or you BSOD. (I'm referring to the CPU core itself, NOT to the IMC or RAM errors--those still will happily make your life interesting).

2) Parity Errors are byebye. No longer will Minecraft generate parity errors due to garbage collection in the caches. Now it just runs. Or you BSOD.

3) The rules have changed for stress testing.

Prime95 "AVX stable" is no longer a valid test for gamers. You can push your 5.2 ghz 11900k overclocks, run small FFT AVX DISABLED Prime95 and get a quick ClocK Watchdog Timeout, because your CPU hates you for you letting it get too hot. You run Cinebench R20 and get a clock watchdog timeout.

Boot up Battlefield 5 (One of the gold standards for stability testing) and it just runs like nothing ever happened. No BSOD, no nothing.

If you want to test if you're stable in games, now you just game. If you're unstable you'll know very fast. The skylake rules are deader than a dead horse.

4) Average overclocks will be a bit lower than what most people expect. 5 ghz all cores will be about the average. Expect about 200 mhz lower than CML chips. However due to stability changes, you may be able to play video games significantly higher than you can run any stress test without random L0 errors. Most 11900k's should be able to game at 5.1-5.2 ghz with HT enabled and 5.3 ghz HT disabled.
I think most gamers will find this a very welcome change to CML "almost stable, but I crashed in COD: Cold War / Minecraft / RDR2" thus not stable overclocks.

Some changes to this new platform:

1) New VRM controller and VRM's. Allows lower v-latch deltas (transients) and lower set vcore when a CML processor is installed vs the previous Z490 motherboards of the same tier. Because Intersil.
Some of the LLC levels are slightly different. But LLC6 is 0.495 mOhm/0.49 mOhm on Maximus 12 Extreme and Maximus 13 Extreme, but M13E needed 20 less mv on my 10900k @ 5 ghz for same stable load voltage (1.146v), and amps draw was also lower!

2) Each core now has its own PLL. This allows independent core clocks to be set on each core. This also greatly improves TVB and Adaptive Clocking, as now all cores can clock up to the TVB frequency on light loads. The favored cores still exist and TVB still exists, with the all core turbo dropping down to 4.8 ghz under heavy loads.

There are now configurable limits for max auto voltages, due to users being afraid of too high voltages. You can configure them in "Auto Voltage Caps."

3) AVX 512 support.

4) AVX guardbands can now be configured independenty in the BIOS, and AVX512, AVX2 and AVX can also be manually disabled. Not that I would recommend disabling it but the option is there if you so choose. AVX guardbands allow voltage scaling during AVX loads (basically how much voltage is increased. 1.00=no increase, 1.25x=1.25 scale factor). Most users won't need to adjust this, but if you're experiencing stability issues and your cooling permits, you may want to look at this.

AVX offsets are different due to each core having its own PLL (see #2). The AVX offset references each core's ratio rather than the all core ratio, depending on how many active cores are referenced. So if Core #0 has a multiplier of x52 and encounters an AVX workload with a negative AVX offset of -2, that core will drop to x50, while the other cores will not be affected! However if an all core AVX load happens, the all core ratio will kick in and limit all the cores to the "All core" ratio limit, with the negative per core offset only referencing the original value. If you want the ratio to go below the all core limit, then you need to lower the offset even more. So in other words, AVX offset is referenced against each individual core's ratio limit, unless the all core offset is greater (lower) than the all core ratio limit value.

5) BCLK overclocking is changed slightly due to the PLL. People pushing very high BCLK will be able to adjust a PVD threshold (a divider) when pushing extremely high BCLK. I don't do BCLK overclocking, but LN2 and world record seekers, especially some of the guys who love RAM bandwidth, will be happy this function exists. This divider is /15 by default, based on 100 mhz reference clock, and the threshold to switch to a x2 post divider is going to be 15. The x4 and x8 dividers come from the PLL, from the x2 threshold, and this can cause problems when pushing the BCLK extremely high. I'm talking about 200 mhz BCLK and higher here. If you encounter failures, please reduce the PVD thresheold. People wanting to push their RAM past normal limits or bypass normal multiplier limitations will enjoy this.

I expect some interesting results with DJR memory and this feature as more users start looking into BCLK + DJR Magic with Gear 2.

6) New Gearing mode (Prep for Alder Lake).

Memory can run 1:1 (synch) mode up to 3733 mhz. This will usually require a hefty increase in VCCIO and VCCSA. 3866 mhz requires work and silicon lottery and sometimes a large increase in IO/SA. 4000 1:1 is possible on SOME chips with maybe 1.65v IO/SA but do not bother. Listen to cstkl1. Just use 1:2. There is no bandwidth penalty from using 1:2 versus 1:1. Ignore the old pre-beta bios leaks. They mean nothing. NDA exists for a reason and people breaking NDA to sell chips early with beta Bioses doesn't help anyone. Shamino did his magic for us and fixed the memory bandwidth issues quickly. If people are still having issues e.g. with single rank, certain RAM kits, etc, please post your specs, RAM kits etc in the Maximus 13 Megathread and details of the issues.

At Gear 1 (1:1) you can use 100:133 only. At gear 2, you can use both 100:100 and 100:133, but 100:100 is significantly worse than 100:133 and is not recommended.

There are now two VCCIO rails on this platform. CPU VCCIO and MemOC VCCIO. MemOC VCCIO is the one that will be most familar to those from Z490.
There is also System Agent voltage, as before.

RTL/IOL tweaking does not seem to work, or no one has figured it out yet.
You can set "Round trip latency" tuning in presets to enabled for now.
Skews are different. Do not expect your old WR, Park, Nom values to work.
Most normal RAM timings and rules will function similar to before.

Unstable memory can cause "00" after failed training sometimes.

There are three memory presets for speed features. Known as "SAGV", you can think of them as "Memory power states, or P-states" Low, Medium and High. They are NOT the same as the "Gear" settings for the controller. It does not make sense to use "Low" frequency if not at XMP (e.g. Jedec) since switching from Low to "Low" 'doesn't make much sense.

Overclocked memory can try the "High" setting (this is full speed gear), but certain memory configurations may fail to boot. This is because certain variables like the Controller/Ram Ratio modes will affect this setting. This setting is disabled by default. It's suggested to simply "enable" this setting and leave the "Gear" configurations at auto and test it there. Overall, there wasn't much benefit to enabling this setting. Try it if you are trying to get the most out of an overclock.

Prime95 30.5 build 2 all AVX disabled, Large FFT is a valid test for memory/IMC stability. If you can run 30 minutes minimum without errors, you should be stable enough for other use.

Setting Command rate 1T may train two additional settings: CMD SLew Rate and CMD Drive Strength. You may see POST CODES 6C and 6A.

There is an integrated Memtest86 stress test in the BIOS. You can test your memory overclock to be able to load windows without a BSOD, without having corrupt memory cells touching a system file.

Important: High cache ratios require a much higher Vcore to switch to that ratio while in windows to avoid crashing, than you need to run stress tests. This is different than CML behavior.

High cache ratios now require MUCH more vcore to run closer to core than CML. VID for cache is higher to much higher than its Core counterpart link. On CML, you could run cache up to its max (fused) ratio. On RKL, you will often need to stay with more down binning because cache VID cannot exceed core VID. If you try to run x51 all core OC and x48 cache and get "Check CPU", well, that's why.

7) V-LATCH!!!!

Not RKL specific, but Asus and Z590 unique. New to Z590 and only Asus has this as far as I know.

Asus' new proprietary hardware circuit is able to record transient min/max values below what the regular controller can read as Vcore, and allows reporting transient voltage true min and max spikes and dips to OS, and the OLED display, just like an oscilloscope. No longer do you need to buy a $300+ 2-4 channel scope to get true vmins! Board can log V-latch max (max spike), V-min (lowest dip) and V-delta (true min to max delta) with a dip switch, enabled for logging, disabled for logging cancel, and can be activated just by running Hwinfo64. Hwinfo EC reporting also has v-latch measurements. Now you can determine your ideal LLC for your workload and save it to a profile.

This is something that users wanted to know for a very long time, just how much the voltage spikes and dips were when they were running different LLC's and vcore levels.

V-latch monitoring is available on the OLED display (no performance penalty) and in HWinfo EC monitoring (some polling penalty as on previous gens, as already known). Requires newest HWinfo version (7.00+).

On my 11900k, I determined LLC5 to have the best overall V-latch delta for min-max with full core non AVX Testing (thanks to Shamino).
LLC5 is 45% reduced vdroop (approx 0.73 mOhm). LLC3 is still the baseline of 1.1 mOhm (Intel spec).

A lot of people will like this and you must choose Asus to use this type of feature. I'm excited about this and it saved me a lot of money over trying to buy a Siglent scope I might only use once, and I put that cost into a nice Fluke DMM instead. Thank you Shamino! (This feature was purely from Shamino's efforts and is a first among any motherboard design).
31,058 Views
35 REPLIES 35

Falkentyne
Level 12
(continued).

-------------------

Both CML and RKL can take use of V-latch logging.
Note, as in M12 series, Hwinfo monitoring of Asus EC will carry some polling penalties when gaming, so for best performance, disable it for gaming and enable it for stress testing. Note that V-latch on the OLED has no performance penalty.

Note to users:
Don't go only by V-latch Delta, as that doesn't tell the whole story. Delta will be very high by using a very light Loadline Calibration level just from vdroop on a heavy stress test. Just like using LLC8 with a test with violent transient swings. What matters is your v-latch min with respect to vcore min, and v-latch max with respect to vcore max. A good balance of a healthy vdroop and transient response is needed for ideal tuning. LLC5 seems to give the most balanced results overall.

LLC levels are similar to Z490 but more improved (especially LLC7):
Loop 0 (CPU core) regulation:

LLC1: 1.7 mOhm (may be default for certain 4 and 6 core SKU's)
LLC2: 1.455 mOhm
LLC3: 1.1 mOhm (default for most 6 and 8 core SKU's and 10 core CML SKU)
LLC4: 1.0 mOhm (recommended for normal /stress OC)
LLC5: 0.73 mOhm (recommended for normal /stress OC / game, best overall V-latch delta)
LLC6: 0.49 mOhm (recommended for game OC)
LLC7: 0.24 mOhm
LLC8: 0 mOhm. Don't use this. May require high VRM switch frequency. Do NOT remove the VRM heatsink.


Some hardware notes:
The left 8 pin power connector is primary and MUST be plugged in on the Maximus 12 Extreme. This may not apply to other boards like the Apex or Hero. Consult the manual to be sure.

Delidding the 11900k is extremely risky due to SMD's next to the die, like HEDT chips. Delid at your own risk.

MCE is enabled by default, you will see this by the F1 prompt after a CMOS clear or first installation. To use Intel default power limits, please disable MCE. Note that MCE does not force all core fixed overclocking, so no fears for overheating chips. Asus tuning is designed to keep the chips under 90C. This temp regulation can be disabled in "AI Features-->CPU Internal Power Management."

My sample uses reasonable power limits for 5.3 ghz on 2 cores, 5.1 ghz on light loads on all cores and 4.8 ghz on heavy loads on all cores. This is going to be sufficient for the vast majority of gamers and people who want good performance without having to change anything in the BIOS except enabling XMP.

----------

Overclocking is very similar to CML. Asus SP rating is accurate for most chips. Of course there will always be some with weak silicon, bad caches or defects (as seen with some users 10900k's that gave CPU Cache L0 errors are stock settings) but these are rare. SP is based on CPU's default VID and doesn't need to be explained again--check the 10900k articles and Asus Z490 posts for more. So you can expect SP 60 chips to do 5.1 ghz all cores game stable, SP 70 to do 5.2 ghz all cores game stable, SP80 to do 5.3 ghz, and so on.

Expect lower SP ratings on this chip than on 10900k. Getting higher than SP80 is pretty much a golden chip for you, congratulations and SP 70+ is above average.
VID levels are also different than expected and with the cache changes, don't expect to compare this to an 8 core 10700k, for example.

Cache levels may need to be -4 or -5 bins below core. Default binning for cache ratio is now much lower than core.
Pushing higher cache requires MUCH higher vcore than before. Please keep this in mind if you forget and try -3 below core and get "Check CPU".

As mentioned before, benchmark / stress test stable and game stable are completely different on this platform. I can play Battlefield 5 with no crashes at 5.2 ghz, 1.520v Bios set + LLC6, Minecraft runs forever, but if I run Prime95 small FFT AVX disabled or Cinebench R20, I get a nice quick Clock Watchdog Timeout. I believe CSTKL1's ES chip sample that has the same SP rating as mine can do CB stable at 5.2ghz but he also has much better cooling as well.

My feedback:

Asus knocked it out of the park with this platform. The Maximus 12 Extreme and Apex were already a home run, with their BIOS and overclocking stability, cool running VRM's and famous high memory overclock and tweaking ability. The Maximus 13 is a grand slam. Yes, concessions were made for RKL's transition to Alder Lake, but this had to be done. Skylake++++ was pushed to its breaking point. RKL needed to happen and things will only improve with ADL's full transition. Expect great things from Intel going forward. Strides not seen since original Core/Core 2 days and Asus to be the shortlist choice for carrying these new platforms.

Stock settings:
5300 mhz (2 cores). 5100 mhz (8 cores-light load). 4800 mhz: all cores, heavy load (ring x39 stock)

Asus stock timings (F1) + XMP:
CB R20: 5985
CB R23: 15538

XMP stock + 5.1 all cores + 4.7 cache:
CB R20: 6395
CB R23: 16540

1.465v set, LLC6
Load vcore: 1.368v
Vlatch min: 1.294v
Vlatch max: 1.463v
Vlatch Delta (min-max): 0.162v
CPU Current: 179A
CPU Core Power (VRM): 244W

Temps: 88C
Cooling: Arctic Liquid Freezer II 360 + Thermalright TFX

--------------

Minecraft (Java) FPS is almost exactly 19% higher than 10900k at the same frequency. And NO WHEA parity errors! A section on the cubecraft server that gave 115-120 FPS in the lobby (10900k, 4.7/4.4 ghz core/ring) was about 145 FPS on a 4.7 ghz/4.2 ghz 11900k.

----------------------

So why choose Asus?

1) V-LATCH !!!!!
2) Accurate die-sense vcore
3) Setting the standard for world record memory overclocks (look at cstkl1's results)
4) New and improved VRM with better transient response
5) Tolerant to high PCIE Slot power draw modded video cards (shunt modded RTX 3090 video cards > 75W)
6) Shamino's presence and Bios updates on the forums.
7) USB Bios flashback is still the best out there.
😎 World record LN2 overclocking champion.
9) Integrated Memtest86 in the BIOS (new). Now you can test your RAM without touching windows to make sure you won't insta-corrupt your partition table going for world record bandwidth.



Why Rocket Lake?

1) Stability. Skylake bugs are gone. This is needed for upcoming platforms. This is going to take many people by surprise, with Parity Errors and L0 errors
gone from random gaming! This is the theme of this platform, even more than the IPC increase of approx 19%.

2) IPC improvement is real and will only get better as Intel moves forward. They deserve a chance and are not disappointing.

3) RKL is indeed a transitional CPU as Intel prepares Conroe 2.0. Compromises had to be made to insure compatibility with CML chips
and ADL's upcoming changes. But this is something people will come to accept. Very excited for how Intel and Asus go forward with this.

This is an excellent post @Falkentyne, thank you! I've actually just purchased a 11700K to replace my 10700K on the back of this, hopefully arriving today!

Do you know how much of the Maximus XIII info you shared applies to the STRIX Z590-E?

What a fantastic post ! Very detailed and in-depth.
Thank you Falkentyne, much appreciated !

Falkentyne
Level 12
No idea about any of the Non Maximus lines. The basic features unique to the chipset should be the same (Gear 1/2, TVB, possibly per core OC, since that is chip specific). Remember the Maximus line is Asus' highest end line, and the M13 Extreme is the entire kitchen sink version of the line.

Falkentyne wrote:
No idea about any of the Non Maximus lines. The basic features unique to the chipset should be the same (Gear 1/2, TVB, possibly per core OC, since that is chip specific). Remember the Maximus line is Asus' highest end line, and the M13 Extreme is the entire kitchen sink version of the line.


Ah OK, thank you anyway!

Backing up what you said about stability of Rocket Lake, I installed my 11700K yesterday and after initial testing at stock frequencies I tried some quick and dirty overclocking by setting MCE enabled and core clocks to 51, 51, 51, 51, 50, 50, 50, 50 running my G.Skill 32GB 3733MHz kit at DDR4000 1.4V 1:2 100:133, leaving adaptive voltage at Auto along with VCCIO and VCCSA. (IIRC HWInfo64 maxed at 1.51V Vcore - is that really 1.42V with it being Socket Sense on the Z590-E?) Got into Windows just fine but wouldn't pass Aida64 or a benchmark in Intel XTU.

(Notably, the system was able to be reset using the reset button whereas my 10700K just randomly cache crashed all the time requiring the long hold of the power button to reset)

I was able to play American Truck Simulator, take a 1.5Hr Zoom call, and do everything else I'd normally use my PC for at those settings with no crashes or anything, really surprising after battling my 10700K for the last week on this board!

Just waiting for some overclocking guides for RKL and what 'safe' voltages are considered as before I dabble any further.

Really impressed so far though, faster more stable performance, running nice and cool as well. The reviews I've read so far on the 11700K couldn't be more wrong...

Thank you again Falkentyne

TasmaN
Level 8
Got 11900KF + Hero XIII + Corsair H150i Pro, all BIOS (0704) settings "Load Optimized" periodically have BSOD with ClocK Watchdog Timeout in daily use, with no stress tests. I Hope it's not defect or something else....can it be fixed by new BIOS in future???

TasmaN wrote:
Got 11900KF + Hero XIII + Corsair H150i Pro, all BIOS (0704) settings "Load Optimized" periodically have BSOD with ClocK Watchdog Timeout in daily use, with no stress tests. I Hope it's not defect or something else....can it be fixed by new BIOS in future???


I have the exact same thing (z590 Rog Strix-E & 11900k and beta BIOS 704). Stock settings with Intel default limits enabled and randomly under light loads it will BSOD with Clock_Watchdog_Timeout. Stress tests are just fine (or heavy games, they also run fine).

We are not alone as you can see here: https://www.reddit.com/r/intel/comments/mnlmwt/new_uefi_bios_updates_for_asus_intel_motherboards/ and here https://www.sweclockers.com/forum/trad/1631356-ny-dator-intel-11900k-samt-asus-prime-z590-a-bsod-hel... (use google translate if you have to, it's worth a read, they even offer some workarounds such as disabling c-states and using LLC lvl 4+).

What worked for me was disabling Hyperthreading because I am currently playing through older lightly threaded games so I lose nothing by doing so. However the loss of performance in modern titles is very significant (from 70 to 50fps in Total War) so this is obviously NOT an acceptable long term solution.

I may try using Asus MCE and manually reducing the power limits (I want my system to be quiet so I love the Intel limits for that reason), perhaps that could be stable too.

But I'm not sure that Asus has even acknowledged the issue yet. And it's been some time since the last BIOS update. Perhaps we should make a new thread.

yeah, we should, a beta bios at launch and no updates for two weeks is not the best thing there is for a highend motherboard...

biglouis wrote:
I have the exact same thing (z590 Rog Strix-E & 11900k and beta BIOS 704). Stock settings with Intel default limits enabled and randomly under light loads it will BSOD with Clock_Watchdog_Timeout. Stress tests are just fine (or heavy games, they also run fine).

We are not alone as you can see here: https://www.reddit.com/r/intel/comments/mnlmwt/new_uefi_bios_updates_for_asus_intel_motherboards/ and here https://www.sweclockers.com/forum/trad/1631356-ny-dator-intel-11900k-samt-asus-prime-z590-a-bsod-hel... (use google translate if you have to, it's worth a read, they even offer some workarounds such as disabling c-states and using LLC lvl 4+).

What worked for me was disabling Hyperthreading because I am currently playing through older lightly threaded games so I lose nothing by doing so. However the loss of performance in modern titles is very significant (from 70 to 50fps in Total War) so this is obviously NOT an acceptable long term solution.

I may try using Asus MCE and manually reducing the power limits (I want my system to be quiet so I love the Intel limits for that reason), perhaps that could be stable too.

But I'm not sure that Asus has even acknowledged the issue yet. And it's been some time since the last BIOS update. Perhaps we should make a new thread.


please try this and let me know if it solves
https://www.dropbox.com/s/0eyrh9dct4p17u2/ROG-STRIX-Z590-E-GAMING-WIFI-ASUS-0013.rar?dl=0