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

Serious Intel CPU bugs (2016)

danluu.com

Post reply on HN
Print view View original

11–20 of 110 posts

Re: Serious Intel CPU bugs (2016)

#11

Post by ta_wh »

mehrdadn wrote: post #10
kuschku wrote: post #8

Earlier quoted context omitted.

Under EU law (this is not legal advice), any bug that wasn't known to you at time of sale, but was present at time of sale, has to be fixed by the vendor. For 2 years after sale usually, some countries have longer (afaik, Norway for example has it set at 5 years. As EEA member, they also follow the EU laws on warranty).

Ahh, I was referring to the US, and bugs that weren't known at the time of sale (I'll edit this in), but thank you, this is still useful information.

See the three-year warranty here for boxed CPUs: https://www.intel.com/content/dam/support/us/en/documents/pr...

Note the first bullet under "WHAT THIS LIMITED WARRANTY DOES NOT COVER":

"design defects or errors in the Product (Errata). Contact Intel for information on characterized errata."

Guess we're not covered on this one.

EDIT: That being said, given the potential scope of this issue (years of affected CPUs, massive PR hit) I'm hoping that Intel will at least offer some remedy to recent buyers. According to the article from The Register [1], OS vendors have been working on the fix since November. The blog posted over on pythonsweetness [2] posits the bug may have been identified in October. It'd be interesting to know for how long Intel has been selling Coffee Lake CPUs that are known to be vulnerable.

[1] https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...

[2] http://pythonsweetness.tumblr.com/post/169166980422/the-myst...

Re: Serious Intel CPU bugs (2016)

#12

Post by lukax »

Is this article from 2015 or 2017?

It would be great if the page displayed the date that the article was posted/updated. It is not in the URL nor the sources. The only way to see the dates is in the RSS feed and even that is only for new articles.

Re: Serious Intel CPU bugs (2016)

#13

Post by slivym »

As a former Intel employee this aligns closely with my experience. I didn't work in validation (actually joined as part of Altera) but velocity is an absolute buzzword and the senior management's approach to complex challenges is sheer panic. Slips in schedules are not tolerated at all - so problems in validation are an existential threat, your project can easily just be canned. Also, because of the size of the company the ways in which quality and completeness are 'acheived' is hugely bureaucratic and rarely reflect true engineering fundamentals. Intel's biggest challenge is simply that it's not 'winning big' at the moment and rather than strong leadership and focus the company just jumps from fad to fad failing at each (VR is dead, long live automotive).

Re: Serious Intel CPU bugs (2016)

#14

Post by paulmd »

Denverton is much more complex than a "simple" Atom (performance of a C3958 is up to about half of an i5-7500 in single-thread, twice the total multi-thread performance). Avoton is really no slouch either. It's really not surprising that the incidence of bugs is increasing on those uarchs as the complexity grows.

The Skylake/Kaby hyperthread bug has been fixed in microcode and is no longer applicable. It's perfectly safe to run HT on these processors now.

The AMD Ryzen segfault remains unmitigated at this point in time. Phoronix rushed to declare the bug fixed because they got a binned RMA replacement but there are plenty of reports of it occurring in current-production processors to at least a moderate degree, roughly proportionate with ASIC/litho quality. It's unclear what the scope is w/r/t Epyc since Epyc is on a different stepping but also hasn't really ramped yet either. The early Epyc processors were essentially engineering samples (on the order of hundreds to single-digit thousands of samples) with no real (public) visibility into any binning that might be taking place.

The Ryzen high-address bug is no big deal, that's the kind of thing that gets patched all the time (like the Skylake HT bug). That's one thing Dan is glossing over here - there are tons of these bugs all the time and as long as there is an effective mitigation available it's no big deal.

The PTI patch can be viewed as making syscalls take somewhat longer (about double iirc). Gamers and compute-oriented workloads won't be hurt hardly at all. The average mixed-workload case sees 5% performance loss, not ideal but it's not critical either. Losing 30% is real bad though, and that's what you will get on IO-heavy workloads that context-switch into the kernel a lot.

The only real mitigation there appears to be right now is to give up hyperconvergence for now and harden up those DB/NAS servers that are going to be pushing a lot of IO so that you know there won't be hostile code running on them. That will allow you to safely disable PTI and sidestep the performance hit.

Of course, Epyc was not that good at running databases in the first place, so you still might be better off sucking it up and running Intel even with the PTI patch. It will probably depend on your actual workload and the relative amount of IO vs processing.

Re: Serious Intel CPU bugs (2016)

#15

Post by mehrdadn »

ta_wh wrote: post #11
mehrdadn wrote: post #10

Earlier quoted context omitted.

Ahh, I was referring to the US, and bugs that weren't known at the time of sale (I'll edit this in), but thank you, this is still useful information.

See the three-year warranty here for boxed CPUs: https://www.intel.com/content/dam/support/us/en/documents/pr... Note the first bullet under "WHAT THIS LIMITED WARRANTY DOES NOT COVER": "design defects or errors in the Product (Errata). Contact Intel for information on characterized errata." Guess we're not covered on this one. EDIT: That being said, given the potential scope of this issue (years of affected CPUs, ma…

Thanks for posting this!

It seems self-contradictory to me. How can Intel warrant that

> the Product will substantially conform to Intel’s publicly available specifications

while simultaneously disclaiming warranty for

> design defects or errors in the Product (Errata)

?

If an instruction does something different than what their specs say on occasion, do they take that to mean it's substantially conforming to their specs?

Re: Serious Intel CPU bugs (2016)

#16

Post by anarazel »

kuschku wrote: post #7
chrisper wrote: post #5

So I recently bought an 8700k. I was wondering if I should rather return it and get AMD instead? Not sure how much the recent bugs will impact me performance wise.

It looks like you'll see a significant slowdown, PostgreSQL with pgbench sees a 7% to 16% slowdown. https://www.postgresql.org/message-id/20180102222354.qikjmf7... Of course, this depends on workload — gaming will see different results than computationally heavy tasks. It is likely that games using Vulkan, DX12 or OoenGL's AZDO functions will see much lower performance impact (because they usually only do a handful o…

But note that that those benchmarks pretty much are the worst case for PTI. Each of the queries is either near trivial (single pkey lookup) or the most trivial (SELECT 1), therefore the send/recv syscalls to/from the clients are taking the most time. If you instead have queries that do a bit more actual work this'd look very different.

Re: Serious Intel CPU bugs (2016)

#17

Post by adtac »

lukax wrote: post #12

Is this article from 2015 or 2017? It would be great if the page displayed the date that the article was posted/updated. It is not in the URL nor the sources. The only way to see the dates is in the RSS feed and even that is only for new articles.

Jan 2016, according to https://danluu.com/ and ctrl+f

Re: Serious Intel CPU bugs (2016)

#18

Post by ta_wh »

mehrdadn wrote: post #15
ta_wh wrote: post #11

Earlier quoted context omitted.

See the three-year warranty here for boxed CPUs: https://www.intel.com/content/dam/support/us/en/documents/pr... Note the first bullet under "WHAT THIS LIMITED WARRANTY DOES NOT COVER": "design defects or errors in the Product (Errata). Contact Intel for information on characterized errata." Guess we're not covered on this one. EDIT: That being said, given the potential scope of this issue (years of affected CPUs, ma…

Thanks for posting this! It seems self-contradictory to me. How can Intel warrant that > the Product will substantially conform to Intel’s publicly available specifications while simultaneously disclaiming warranty for > design defects or errors in the Product (Errata) ? If an instruction does something different than what their specs say on occasion, do they take that to mean it's substantially conforming to their s…

I'm no lawyer, but my instincts tell me someone would have to prove that the chips today do not conform to Intel's specs, and that this difference is such that the CPU no longer "substantially conforms" to the spec.

> If an instruction does something different than what their specs say on occasion, do they take that to mean it's substantially conforming to their specs?

We're on the same page. What do you think Intel will argue?

Keep in mind Intel did initiate a substantial recall of Pentium CPUs in the late 90s: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Re: Serious Intel CPU bugs (2016)

#19

Post by badsectoracula »

kuschku wrote: post #7
chrisper wrote: post #5

So I recently bought an 8700k. I was wondering if I should rather return it and get AMD instead? Not sure how much the recent bugs will impact me performance wise.

It looks like you'll see a significant slowdown, PostgreSQL with pgbench sees a 7% to 16% slowdown. https://www.postgresql.org/message-id/20180102222354.qikjmf7... Of course, this depends on workload — gaming will see different results than computationally heavy tasks. It is likely that games using Vulkan, DX12 or OoenGL's AZDO functions will see much lower performance impact (because they usually only do a handful o…

> or even OpenGLs immediate mode (which does one syscall per emitted vertex, in worst case)

Perhaps with drivers written in the 90s for hardware from the 90s. Any OpenGL implementation worth its salt will buffer those requests on the client side until they need to be observed. Indeed this was a big feature in the heyday of DirectX 9 where D3D programmers had to count the drawcalls whereas with OpenGL you have way more leeway with calls since the driver tends to be smarter and caches that stuff.

In theory with a modern driver using OpenGL's immediate mode API shouldn't need any more syscalls than building the vertex buffers in your program, setting up the necessary state and issuing a buffer draw command.

The only time where you'd need a syscall per emitted vertex would be if the GPU had OpenGL-like commands and your OpenGL implementation was a thin wrapper over that. I think one of ATI's very early GPUs worked like that (although the commands were per primitive, not per vertex).

Re: Serious Intel CPU bugs (2016)

#20

Post by aristidb »

chrisper wrote: post #5

So I recently bought an 8700k. I was wondering if I should rather return it and get AMD instead? Not sure how much the recent bugs will impact me performance wise.

The very article mentions at the bottom that AMD has its fair share of nasty bugs recently, too. If anything, I would expect AMD to spend even less effort on validation (because they are not flush with cash).
Post reply on HN