Roman “Der8auer” Hartung has accused GIGABYTE and their in-house overclocker Hicookie for publishing fake world record overclocking results which were afterwards used for marketing materials for their motherboards.
In a recent video, Roman concludes his video by positing his findings and concluding that 8Ghz is not readily attainable in the new Intel Core i9-12900K in extreme overclocking and wishes brands to not claim anything upwards of 8Ghz or more. He then quickly cuts in after 2 hours after the video recording and then proceeds to stomp a mudhole in Gigabyte’s declining reputation with Gigabyte claiming 8ghz overclock on their marketing materials as performed by Hicookie.
Roman is visibly displeased by this and is very vocal about revoking the validity of this claim. The main argument is that GIGABYTE is publishing 8Ghz as validated in CPUZ which runs a Cinebench stress on the system while only publishing only 6.8Ghz of Cinebench score instead of the 8Ghz. Overclocking politics aside, this can be attributed to just a frequency claim but regardless, doubting results is a practice in the overclocking community and as such, many verification results are required to accept a record run. Roman and Hicookie are very tenured and known figures in the extreme OC scene and they know full well the marketing value of these results, despite actual, real-world buyers never really caring much.
“I’m really mad. This is hurting your own marketing, but its also hurting the x-OC community. And that’s something I cannot accept.”
Roman declares that he will discuss this with HWBot, the overclocking community and validation organization, and if they find that this results are invalid and have been posted in HWBot. Hicookie will receive a lifetime ban for this actions.
Update: CPU-Z dev acknowledges misreporting bug in Alder Lake
CPU-Z developer have published a statement that Intel Alder Lake has a bug that may lead to misreporting. The full statement is below:
Almost everyone reported that 8 GHz overclocking on Alder Lake, supported by screenshots from the CPU-Z Validator. Well, here is why it’s very unlikely that this CPU really reached 8 GHz. ⤵️
PS: I’m the developer of the CPU-Z Validator.
First, we have been talking to motherboards manufacturers, Intel’s team and many major overclockers on a daily basis for several months about ADL overclocking. A lot of talented overclockers all over the world spent a lot of time trying to reach world-records since weeks.
We started to see the first “hard-core” ADL overclocking in early September. Almost immediately, a silicon errata was found with ratio set at > 63. In some rare conditions, the internal CPU PLL fails to lock and remains at the previously set ratio while reporting the new one.
Quickly, we received many 8/9/10/12+ GHz fake “overclocking” on early Alder Lake samples. As it was way too late to patch the issue on silicon (and not really a big thing for 99.99999% of Intel’s customers), Intel team worked their ass off to found a fix. Congratz to them!
The fix was implemented in a new microcode update (0x12) by adding a new HW register called FLL_OC_MODE. When enabled and set properly, the internal CPU insure that the PLL is correctly locked with ratio > 63. The report for FLL_OC_MODE was implemented in CPU-Z 1.98.
On the validator side, about a month ago, I’ve added a lot of additional checks (microcode version, core throttling, fll_oc_mode register checking) to invalidate the already-posted entries that exploited the issue. Everyone played quite a lot just for fun, so it was necessary.
For the last 4 weeks, all big overclockers linked to motherboards makers worked seriously on ADL with these new fair rules. The overall consensus was that full all-cores benchmark stability is possible at around 7 GHz and “suicide run” on single core up to 7.5-7.6 GHz.
WR records between 7.5 and 7.6 GHz were set and broken almost each days, by a few MHz at most. many overclockers tried a lot of CPU (20/50/100+ samples) to grab the golden ones able to reach these frequencies … or a few MHz higher
Then suddenly, some days ago, we saw a unique 8 GHz validation popping from nowhere. Knowing that tens of overclockers tested hundreds of CPUs on a bunch of motherboards while all struggling around 7.5 GHz, that’s quite suspicious at least…
Was the PLL lock bug back, this time on a way we can’t detect as it passes all internal checks? Seems legit. Technically, we can think about a way to trick the CPU if we have access to BIOS source code (some overclockers working with MB makers have them).
It basically involve first messing with CPU ratio, then upgrade the microcode, and finally set the FLL_OC_MODE to enabled, all at boot time. That could led to a situation where the flag is enabled but the CPU still at a much lower ratio than reported.
In all cases, it’s necessarily intentional because this involve a lot of complex operations and messing with early boot stages. Intel team worked on this and found a way to check if the PLL is really locked by messing quite badly with some performance MSRs.
Problem: if the PLL is not locked, the whole CPU will hard-lock immediately, needing a reboot to recover. That’s something we can’t implement in CPU-Z because all Windows crashes are reported by Microsoft’s mandatory telemetry Grimacing faceand we can be banned by Windows Defender for that.
There’s nothing we can do on our side right now.Worried faceThe issue is now on Intel’s hands, needing a new hardware stepping or maybe another microcode patch. Solving such a niche issue to prevent ppls messing with BIOS source code is a real challenge and probably not on the top list.