Hacker News Reader

Comment by imtringued | Hacker News Reader

Server CPUs are way too cheap compared to the remaining parts of the server. Paying 10% more in exchange for software compatibility is a steal.

View on HN

Until your single-source vendor decides to turn up the heat. Realistically if Intel doubled all prices tomorrow most enterprise customers would just pay it.

The huge cloud vendors should be buying and deploying AMD systems right now to ensure that never happens; it doesn't matter if there are some kinks to iron out. As an insurance policy it is very cheap.

What software compatibility issue?

Different CPUs perform subtly different. Not to mention that server-class workloads tend to expose bugs and architectural shortfalls. Ryzen hasn't had great press in this regard, so decision makers are going to regard AMD with some skepticism to begin with. It's about risk: you know Intel chips roughly perform as they always have, just a little better each generation.

Additionally, if you rely on Intel's compiler to get more performance out of your chips, well, switching to AMD doesn't make a whole lot of sense.

AMD needs to be back in the server space for a while before they'll be trusted again.

What's a server class workload in this context?

Remember that Intel's embarrassing FDIV bug was spotted in Excel...

I agree with most of what you said, but Kaby Lake had issues with Hyperthreading, and Haswell had to fully disable the TXT extensions, both modified (fixed/disabled) through microcode updates. You could say Intel hasn't had great press either.

That being said, I still agree AMD still needs to prove their new platform in the server space.

For what it's worth, it's TSX (hardware transactional memory), not TXT (secure firmware). It's a very niche feature, compared to hyperthreading.

Don't you know AMD and Intel aren't compatible.

Not the OP, but maybe he's talking about the kernel panic that some users are getting during heavy-duty compilation workloads.

https://www.phoronix.com/forums/forum/hardware/processors-me...

Newer steppings of Ryzen have a fix applied, and AMD is allowing people to RMA those processors affected. Threadripper is unaffected by the bug.

Source: https://www.phoronix.com/scan.php?page=article&item=new-ryze...

AMD has never stated that there is a fix for this. If you look at the link you posted, this is Larabel making this claim on the basis that he hasn't seen any forum posts noting this problem on samples manufactured after week 25. Quote:

> AMD has not provided an official public explanation of the fundamental problem, but from those in our forums and elsewhere, it appears to affect Ryzen CPUs manufactured prior to week 25.

This problem only affects a minority of chips in the first place (likely a litho flaw in the cache section), it's probable that Larabel's second CPU just didn't happen to be one of the ones with problems. And Week 25 ends June 25, i.e. stock for these date ranges has hardly even made it through packaging/distribution to end users let alone been extensively tested yet.

Larabel is jumping the gun on insufficient evidence and people are racing to make the claim that AMD has fixed this, when that's far from the case. AMD certainly hasn't made any statements to this effect.

AMD is RMA'ing afflicted units, which is really all that can be done until they get a new stepping out. But I've seen no evidence that this is actually fixed.

> This problem only affects a minority of chips in the first place (likely a litho flaw in the cache section)

What are you basing this on? I've seen no good reporting on this* but the AMD Community segfault thread (https://community.amd.com/message/2796982) seems to suggest that almost all Ryzen CPUs manufactured before the end of June (which I assume is most of the current stock) are affected. Very few people load their Ryzens sufficiently to hit this bug, but a large number of those who attempt it seem to get the segfault.

* I would like to know the percentage of processors with the bug, percentage of review units with the bug (I would be very interested in this), and maybe some long-term testing of "bug free" processors etc.

It may be ridiculous, but I'm not spending a million dollars on CPUs with information gleamed from a forum post.

It's not ridiculous, but there's pratically no more information about it. No major tech sites have covered it, beyond Phoronix. AMD haven't acknowledged it, beyond stating that "a performance marginality problem exclusive to certain workloads on Linux" exists, which is factually incorrect as it also seems to occur on other operating systems.

I'm not spending hundreds of euro on a processor without knowing something more concrete about this issue. If you budget is really ~million dollars, do you have additional information about this that you can share?

My ~$400 CPU budget went toward a Skylake i7 a couple of years ago, I'm afraid.

there is no kernel panic whatsoever. the mentioned issue causes some of your GCC parallel compilation jobs to fail, everything happens in user level. This issue is caused by manufacturing, not by design, it has been fully addressed in recent batches.

At least there are some linux kernal support issues on AMD Ryzen and Threadreaper CPUs for now.

There is a fix for Ryzen in newly shipping chips which fixes the gcc compilation issue on Linux. From what I understand if you are facing the issue you can contact AMD and they will ship you a new chip without the issue. ThreadRipper / Epyc never suffered from the issue.

> linux kernal

Its "kernel", btw.

I'm having so much fun reading this: https://ubuntuforums.org/archive/index.php/t-78107.html

A several people have replied to you by mentioning the Ryzen kernel panics. That's a thing and it's getting fixed by hook or by crook, but it's not everything. Here[1] is an example; Ryzen only received no-workarounds-needed support for ESXi 30 days ago. Another[1]; you can't monitor CPU temps in Linux yet for lack of driver support. That sort of thing is a non-starter in a cloud data center when you're managing megawatts. The truth is that the 'enterprise' has been wrapped around the Intel axle for years and AMD has a lot of catch up to do before it has parity with Intel.

There are enterprise people that will adopt AMD for the shear $/compute value, but until you can find rackable Dell SKUs and Supermicro server motherboards with AMD sockets and the whole 'enterprise' software stack is fully ironed out Intel can and will command a premium. It will happen, eventually (assuming AMD continues to compete,) but it's not here yet.

[1] https://www.reddit.com/r/Amd/comments/6que0q/esxi_65_now_wor... [2] http://www.phoronix.com/scan.php?page=article&item=amd-ryzen...

Ah, the classic "computers are cheap, developers and software is expensive" argument. That may apply for small companies, but when you've got 100's of millions or billions of dollars worth of hardware, 10% starts to easily be worth the developer investment.

Intel agreed to license the x86 to AMD decades ago, it is the precondition to allow Intel to avoid being sued to bankruptcy for monopoly. For current software, the current arch is called AMD64 for a reason - the mentioned compatibility is built entirely on AMD inventions.

Not only to avoid enforcement, but also because some customers will only select products where a https://en.wikipedia.org/wiki/Second_source is also selling them.

Well that's stretching the meaning of second sourcing quite a lot. Normally it means that you can get an exact replacement part from someone else. For example, industry standard things like nuts, bolts, ball bearings, SRAM and DRAM (most stuff specced by JEDEC) can be sourced from many sources. There is literally no difference at all between a M8×20 8.8 bolt between manufacturer A and B. Similarly, if you have a design with a LM358 (a non-standardised part), then there are multiple manufacturers that will sell you a part with identical specs under a slightly different name or even the same name.

This is also the way it started with x86 and other second-sourceable processors. An Intel 8086 and an AMD 8086 are drop-in compatible. This is not the case with modern processors, they don't even fit the same sockets.

But you can change a larger module. If you want to cover that kind of risk with that kind of supplier companies (hint: a marginal risk, to begin with), you are not going to go anal about the drop it characteristics of single chips. Or at least you should not, IMO.

Reply on news.ycombinator.com