Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

community.intel.com

Post reply on HN
Print view View original

161–170 of 216 posts

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#161

Post by ComputerGuru »

Dylan16807 wrote: post #96
ComputerGuru wrote: post #94

Earlier quoted context omitted.

> If you have a program that can use more than 8 cores, then that 8P+12E CPU should approach a 14P CPU in speed Only if you use work stealing queues or (this is ridiculously unlikely) run multithreaded algorithms that are aware of the different performance and split the work unevenly to compensate.

Or if you use a single queue... which I would expect to be the default. Blindly dividing work units across cores sounds like a terrible strategy for a general program that's sharing those cores with who-knows-what.

It’s a common strategy for small tasks where the overhead of dispatching the task greatly exceeds the computation of it. It’s also a better way to maximize L1/L2 cache hit rates by improving memory locality.

Eg you have 100M rows and you want to cluster them by a distance function (naively), running dist(arr[i], arr[j]) is crazy fast, the problem is just that you have so many of them. It is faster to run it on one core than dispatch it from one queue to multiple cores, but best to assign the work ahead of time to n cores and have them crunch the numbers.

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#162

Post by ComputerGuru »

Sohcahtoa82 wrote: post #125
ComputerGuru wrote: post #94

Earlier quoted context omitted.

> If you have a program that can use more than 8 cores, then that 8P+12E CPU should approach a 14P CPU in speed Only if you use work stealing queues or (this is ridiculously unlikely) run multithreaded algorithms that are aware of the different performance and split the work unevenly to compensate.

> run multithreaded algorithms that are aware of the different performance and split the work unevenly to compensate. This is what the Intel Thread Director [0] solves. For high-intensity workloads, it will prioritize assigning them to P-cores. [0] https://www.intel.com/content/www/us/en/support/articles/000...

Then you no longer have 14 cores in this example, but only len(P) cores. Also most code written in the wild isn’t going to use an architecture-specific library for this.

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#164

Post by gwbas1c »

phire wrote: post #100

I find it hard to believe that it actually is a microcode issue. Mostly because Intel has way too much motivation to pass it off as a microcode issue, as they can fix a microcode issue for free, by pushing out a patch. If it's an actual hardware issue, then Intel will be forced to actually recall all the faulty CPUs, which could cost them billions. The other reason, is that it took them way too long to give details.…

It's most likely both a hardware issue and a microcode issue.

Making CPUs is kind-of like sorting eggs. When they're made, they all have slightly different characteristics and get placed into bins (IE, "binned") based on how they meet the specs.

To oversimplify, the cough "better" chips are sold at higher prices because they can run at higher clock speeds and/or handle higher voltages. If there's a spec of dust on the die, a feature gets turned off and the chip is sold for a lower price.

In this case, this is most likely an edge case that would not be a defect if shipping microcode already handled it. (Although it is appropriate to ask if it would result in effected chips going into a lower-price bin if they are effected.)

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#165

Post by paulmd »

Sakos wrote: post #134
sirn wrote: post #127

Earlier quoted context omitted.

The problem may exist, but Alderon Games' report on the mobile chip is more of an anecdote here because there's not enough data points (unlike their desktop claims), and the only SKU they give (13900HX) is actually a desktop chip in a mobile package (BGA instead of LGA, so we're back into the original issue). So in the end, even with Alderon's claims, there's really not enough data points to come to a conclusion on t…

Why are you downplaying it too? > "The laptops crash in the exact same way as the desktop parts including workloads under Unreal Engine, decompression, ycruncher or similar. Laptop chips we have seen failing include but not limited to 13900HX etc.," Cassells said. > "Intel seems to be down playing the issues here most likely due to the expensive costs related to BGA rework and possible harm to OEMs and Partners," he…

Alderon are the people claiming 100% of units fail which doesn’t seem supported by anyone else either. Wendell and GN seem to have scoped the issue to around 10-25% across multiple different sources.

Like they are the most extreme claimants at this point. Are they really credible?

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#166

Post by paulmd »

wmf wrote: post #81
guywithahat wrote: post #63

Earlier quoted context omitted.

That’s probably where people are mostly likely to understand it. A lot of companies do this, especially while they’re still learning things.

These days people are more likely to see the announcement on YouTube, TikTok, or Twitter.

they did that too

https://youtu.be/wkrOYfmXhIc

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#167

Post by paulmd »

sudosysgen wrote: post #109
salamo wrote: post #108

Is there any info on how to diagnose this problem? Having just put together a computer with the 14900KF, I really don't want to swap it out if not necessary.

Running a full memtest overnight and a day of Prime95 with validation is the traditional way of sussing out instability.

it’s also a terrible stability test these days for the same reasons Wendell talks about with cinebench in his video with Ian (and Ian agrees too). Doesn’t work like 90% of the chip - it’s purely a cache/avx benchmark. You can have a completely unstable frontend and it’ll just work fine because prime95 fits in icache and doesn’t need the decoder, and it’s just vector op, vector op, vector op forever.

You can have a system that’s 24/7 prime95 stable that crashes as soon as you exit out, because it tests so very little of it. That’s actually not uncommon due to the changes in frequency state that happen once the chip idles down… and it’s been this way for more than a decade, speedstep used to be one of the things overclockers would turn off because it posed so many problems vs just a stable constant frequency load.

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#168

Post by paulmd »

Night_Thastus wrote: post #71

"Elevated operating voltage" my foot. We've already seen examples of this happening on non-OC'd server-style motherboards that perfectly adhere to the intel spec. This isn't like ASUS going 'hur dur 20% more voltage' and frying chips. If that's all it was it would be obvious. Lowering voltage may help mitigate the problem, but it sure as shit isn't the cause.

Specifically I think the concerns are around idle voltage and overshoot at this point, which is indeed something configured by OEMs.

edit: BZ just put out a video talking about running Minecraft servers destroying CPUs reliably, topping out at 83C, normally in the 50s, running 3600 speeds. Which is a clear issue with low-thread loads.

https://m.youtube.com/watch?v=yYfBxmBfq7k

Re: July 2024 Update on Instability Reports on Intel Core 13th/14th Gen Desktop CPUs

#169

Post by burnte »

phire wrote: post #100

I find it hard to believe that it actually is a microcode issue. Mostly because Intel has way too much motivation to pass it off as a microcode issue, as they can fix a microcode issue for free, by pushing out a patch. If it's an actual hardware issue, then Intel will be forced to actually recall all the faulty CPUs, which could cost them billions. The other reason, is that it took them way too long to give details.…

> I find it hard to believe that it actually is a microcode issue.

They learned a lot from the Pentium disaster, even if it's a hardware issue, they can address it with microcode at least, which is just as good.

Post reply on HN