Still unlikely to be a problem. What could be a (is probally the) problem is MCE.
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.
MCE is a collection of settings that can vary from one mobo manufacturer to another, in both scope and values. The more appropriate way of addressing this issue is to consider and discuss particular settings or limits that may lead to instability. I happen to agree with others in this thread who think that ICC_max is a very likely candidate. (or at the very least the first setting to bring back to stock before figuring out the problem by tiral and error)Still unlikely to be a problem. What could be a (is probally the) problem is MCE.
MCE is a collection of settings that can vary from one mobo manufacturer to another, in both scope and values.
It’s 160W, what’s the point of cherry picking when the results are already quite lopsided? Intel’s gaming utility doesn’t disable “Cinebench” ecores. It disables 1 or 2 e-cores per cluster so that there is more L2$ available per ecore.49W vs 188W in gaming, 3.8x power consumption of AMD. I guess thoseCinebenchE-cores really help with "gaming efficiency", amirite? It's no wonder Intel's new "gaming accelerator" utility disables them.
This post hit all of the cliche AMD-homer talking points and was dripping with bad faith. I don’t get the point of this type of stuff. I guess it probably felt cathartic for you while typing it out though.508W in multi-threaded workloads with no power limit. Remember, that's what virtually every Intel enthusiast mobo does when you enable XMP.
Even at stock, "253W TDP" is nowhere to be found. Again, I wonder why Intel still isn't mandating reviewers lock PL1 / PL2 and disable XMP, despite Intel being aware their CPUs fail certain workloads. Hmmm, what could the reason be?
Comedy gold.
No it doesn't. There is a max all core turbo by default for the P cores that is typically 200 MHz below the single core turbo. There is also TVB which depending on temp will have an even higher delta between all core and single core. In the case of the 14900 KS the all core is 5.7, single core is 5.9 (turbo boost 3.0), and the TVB is 6.2.The issue is that MCE sets the all core turbo to whatever the single core turbo is... and if you get a dud chip, the chip may not be able to do that.
No it doesn't. There is a max all core turbo by default for the P cores that is typically 200 MHz below the single core turbo. There is also TVB which depending on temp will have an even higher delta between all core and single core. In the case of the 14900 KS the all core is 5.7, single core is 5.9 (turbo boost 3.0), and the TVB is 6.2.
I am not going to ding/report you for it, but how many times do we have to go over this? Attack the post, not the poster. The first part of your post was cogent and informative. By going after the person it becomes flame bait, inviting return fire. Which only serves to obfuscate the topic and is unconstructive to the dialogue. Engage them with facts, data, and personal experience with the hardware, not personal attacks.This post hit all of the cliche AMD-homer talking points and was dripping with bad faith. I don’t get the point of this type of stuff. I guess it probably felt cathartic for you while typing it out though.
There are predefined clock multipliers for the P cores depending on how many cores are utilized. The CPU will run the P cores at the all core turbo multiplier during Tau without MCE. The CPU should be stable at stock clocks even with MCE because it's designed and binned to run at that freq during TAU. If it's not it should be replaced under warranty. Your speculation about instability while running at the all core max is baseless. There are also temperature limits that are likely to prevent the CPU from maintaining the all core frequency indefinitely without an extreme cooling solution. Since you're clearly unfamiliar with how turbo, Tau, power limits, and temp limits work on a modern Intel platform, and appear to have not spent any time playing around in an LGA1700 UEFI, you should probably stop commenting about it.200 Mhz might not sound like much but it could be all the difference.
There are predefined clock multipliers for the P cores depending on how many cores are utilized.
The CPU will run the P cores at the all core turbo multiplier during Tau without MCE.
The CPU should be stable at stock clocks even with MCE because it's designed and binned to run at that freq during TAU.
This is why VID is a thing.Not necessarily.
While all true I'd think once we are at that point we are talking about much more corruption than what the OP is about.A parity bit will only protect against a single bit error. If the higher power is making errors more likely than it's also making double bit errors more likely and those will go undetected because the parity will still check out. The higher voltage needed to push the clocks would also make tunneling more likely so we would expect an increase in the chances of bits flipping somewhere along the line.
Absolutely necessarily. All cores must be able to boost to advertised clocks, each core has it's own VID table to make sure it hits those clocks safely. Final VID request is obtained by pickng the max VID requirement from all cores on the voltage rail, including a variable offset introduced by load line mobo settings.Not necessarily.
My hypothesis is that Vdroop is causing the actual instability issue, and I suspect reducing ICC_max is just a round about way to solve it. I'd be interested to find out what would happen if the people in the reddit thread bumped LLC up a level or 2 instead of limiting ICC_max. I think this probably would have also prevented stability issues during shader compilation. As would a sane temperature limit although that is pretty much just an alternative way to limit current.I happen to agree with others in this thread who think that ICC_max is a very likely candidate. (or at the very least the first setting to bring back to stock before figuring out the problem by tiral and error)
Which begs the question ...Why doesn't intel put the leash on their board partners default settings if they're going to officially support these kind of power limits with these extreme power delivery profiles?The 307A limit for ICC_max is old news now, the new limit is 400A. New PL1=PL2=320W, but who enforces that anyway...
Zen 3. Then V-cache. Then Zen 4. Then V-cache of that too. By the time Zen 5 is done, reviewers may be recommending everyone to move to the South Pole to truly enjoy a top end Intel CPU without thermal throttlingWhat the hell happened?
Also, if you have anything that takes more than 8 heavy tasking cores or avx-512 or runs for more than 10 minutes, the 14900k/ks can't touch a 7950x (both at stock).Zen 3. Then V-cache. Then Zen 4. Then V-cache of that too. By the time Zen 5 is done, reviewers may be recommending everyone to move to the South Pole to truly enjoy a top end Intel CPU without thermal throttling
But psychologically speaking, people just love big numbers. That's why quite a few folks will throw their money on really expensive (both initial cost and long run cost) 14900KS rigs, just to feel content that they have the "fastest" CPU on the planet.
Bulldozer/Piledriver was a bad product and so are these K(S) SKUs from Intel.And now this is just a normal and acceptable power limit for Intel's main CPU?
The Intel monopoly sat on their rectum for 7 years and allowed AMD to overtake them.What the hell happened?
Intel was dead in terms of innvoation in the last decade. Their IFS cannot even now ramp up Arrow/Lunar because of lack of ASML machines, needs TSMC. That will change in a few years if they secure enough machines for their own nodes.What the hell happened?
Bulldozer/Piledriver was a bad product and so are these K(S) SKUs from Intel.