Jay weighed in on the topic. Buildzoid explains better in the comments -
So the thing is intel programs a voltage frequency curve into the CPU. When the motherboard removes the power and current limits. The CPU will request insane voltages because it's not hitting the power or current limits. So technically the motherboard isn't feeding more voltage than the CPU is requesting. However if the power limits were being properly enforced the CPU wouldn't be able to request insane voltages.
So the problem actually is that Intel allows the embedded voltage frequency curve to extend linearly or worse exponentially even beyond sane voltage levels?"intel programs a voltage frequency curve into the CPU. When the motherboard removes the power and current limits. The CPU will request insane voltages because it's not hitting the power or current limits"
No. That's not it. Buildzoid is only hinting at what is happening.So the problem actually is that Intel allows the embedded voltage frequency curve to extend linearly or worse exponentially even beyond sane voltage levels?
Of course Intel should disallow it. But they don't, and we all know why.That prolly should be disallowed at "stock".
Yes, my guess is that board makers probably have done some 'binning' of their own to figure out some statistic of the distribution of CPUs that can get away with manipulating the control parameters to an extent like - say 20% higher IccMax above spec.@tamz_msc so old school electrical manipulation essentially? That prolly should be disallowed at "stock".
Yep, exactly. I powercap my CPU @ 65W and GPU @ 130W. I'm absolutely done with gaming on furnaces.Whether DIY builds boost to 250W or 150W pales by comparison, and I write this from a 12700K with PL1=PL2=120W so I'm a firm believer in energy consumption with common sense.
I think they might be doing it only with K CPUs because their understanding is that people buy these CPUs to torture them so why not torture it FOR them. Do I make sense?So they are tricking the SVID to request more voltage than it actually needs by manipulating the VR feedback loop.
Yes, that is entirely possible.I think they might be doing it only with K CPUs because their understanding is that people buy these CPUs to torture them so why not torture it FOR them. Do I make sense?
So the locked CPUs don't have this problem? i.e. i9 13900 (non k)??Yes, that is entirely possible.
From the horses mouth, with emphasis added:So the locked CPUs don't have this problem? i.e. i9 13900 (non k)??
RAD has become aware of a problem that can cause Oodle Data decompression failures, or crashes in games built with Unreal. We believe that this is a hardware problem which affects primarily Intel 13900K and 14900K processors, less likely 13700, 14700 and other related processors as well.
Has Intel issued any kind of statement regarding this issue??From the horses mouth, with emphasis added:
They did reply to Epic/RAD and advised customers how to apply settings in BIOS which should prevent this problem.Has Intel issued any kind of statement regarding this issue??
Yes...makes perfect sense. Bad for business if they don't...They did reply to Epic/RAD and advised customers how to apply settings in BIOS which should prevent this problem.
Intel Processor Instability Causing Oodle Decompression Failures
RAD Game Tools' web page. RAD makes Bink Video, the Telemetry Performance Visualization System, and Oodle Data Compression - all popular video game middleware.www.radgametools.com
I think it's an OK response because that should fix the issue for users. But I'd also like to see them prevent board vendors from applying these out-of-the-box misconfiguration options for the next generation of boards.
Especially given the following if it is correct.Yes...makes perfect sense. Bad for business if they don't...
Not necessarily being caused be the kinds of loads Oodle is applying, it's just being caught by Oodle and throwing an error. Other heavy workloads might catch and retry without an obvious error or might just not notice it.This is being seen disproportionately in Oodle Data decompression because unlike most gameplay, simulation, audio or rendering code, decompression needs to perform extra integrity checks to handle accidentally or maliciously corrupted data, and is thus likely to spot inconsistencies very soon after they occur. These decode failures then typically result in an error message.
It's not clear if the data is getting corrupted in the caches or the memory controller or somewhere along the data paths.Makes me wish ECC memory would be standard in mainstream PCs. It's a shame it still isn't.
Intel technically made it easier on Alder Lake gen to have ECC since all 12500/13500/14500+ supports it (EXCEPT F series. No IGP, no ECC). You just need a W680 or R680E Chipset. Heck, W680 can overclock, it is pretty much a Z690 with TXT and ECC support. Support for both DDR4 and DDR5 even gives you choice based on UDIMM ECC availability. Sadly, there aren't that many viable motherboards with those Chipsets.Makes me wish ECC memory would be standard in mainstream PCs. It's a shame it still isn't.
At the price they are asking for W680 mobos, they don't have minimum six RAM slots which makes me angry for a teensy weensy nanosecond and then I'm over it.Also, W680 wasn't refreshed with 700 series silicon so you're missing 8 PCIe Lanes upgraded from 3.0 to 4.0, which I'm angry about.
Unfortunately the power consumption numbers from the Techpowerup review tell the same story we've seen in this thread, the one that probably contributes to system instability issues in the OP. There are several benchmark runs where the "stock" 14900KS reaches 350W+ average power consumption on the Asus Z790 Maximus Hero. According to Intel, the maximum turbo power of 14900KS should be 253W. With peaks certainly going well over 370W, I think there's a high chance that stock ICC_max isn't enforced either.I would suggest the forum overseers shut this thread down.
While not full ECC, caches are essentially protected by the parity bit. With DDR5 the memory chips themselves are also protected internally. It's only the IMC and the paths in between it and the memory left doing whatever it wants.It's not clear if the data is getting corrupted in the caches or the memory controller or somewhere along the data paths.
While not full ECC, caches are essentially protected by the parity bit. With DDR5 the memory chips themselves are also protected internally. It's only the IMC and the paths in between it and the memory left doing whatever it wants.