Return i5 8600K and get a ryzen or later a ryzen+?

[Alexander]

Would you try to return an unboxed sealed new  boxed i5 8600K and wait for ryzen+?

 

I'm beginning to regret I bought it now with Meltdown and also this Intel ME bug Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets. 

 

My intention is to try to build a small UnRaid server for home use with it and try UnRaid.

 

Next priority is backup (that is crucial) and then a UPS after that if I end up liking UnRaid.

 

For sure I would advise new builders to avoid Intel and go AMD from now on for servers. But I'm a complete newbie in this field. Any thoughts on this?

[pwm]

2 hours ago, Alexander said:

 

For sure I would advise new builders to avoid Intel and go AMD from now on for servers. But I'm a complete newbie in this field. Any thoughts on this?

 

Remember that there are two security issues found.

 

One is Intel-specific (Meltdown) and the workaround fixes are rolling out right now.

 

The other is not Intel-specific (Spectre) and even if the initial attack code was written for Intel processors, it affects AMD too. Currently they have mentioned Intel, AMD and ARM but since it basically circles around MMU + cache + speculative execution it's likely to affect other processors too. Any processor good enough that anyone would be interested in it for a "real" computer has MMU + cache + speculative execution.

 

And for Spectre, there aren't really any good solutions. The main rule is: don't run code you don't trust. Not even in a sandbox.

[SSD]

5 hours ago, Alexander said:

For sure I would advise new builders to avoid Intel and go AMD from now on for servers. But I'm a complete newbie in this field. Any thoughts on this?

 

For sure AMD has made great strides, but there continue to be challenges with the Ryzen and TR CPUs with unRAID.

 

If you want a troublefree unRAID experience, I would advise Intel vs AMD at this point in time. The 8700K with its 6 Cores and over 16000 passmark would make a great CPU for unRAID.

 

I personally would not trade it for an AMD at this point in time.

[Alexander]

16 hours ago, pwm said:

One is Intel-specific (Meltdown) and the workaround fixes are rolling out right now.

Yes but the workaround will decrease intel CPU performance. Possibly maybe 10% with UnRaid (speculation says 5-30%). NAS and VMs are in the worser range maybe even 10-50% and if that proves to be true it is really bad for intel. In a video on youtube JaysTwoCents 7:05 there is also speculation that "people" will attack the Meltdown OS fixes. Don't listen to the link (waste of time) it's there for reference.

 

16 hours ago, pwm said:

Any processor good enough that anyone would be interested in it for a "real" computer has MMU + cache + speculative execution

Yes but AMD says that ryzen do not leak this cache data (at least not with the Meltdown scenario). Ryzen MMU (Memory management unit) is better protected against access to cache data of other processes even in complex code scenarios using code prediction and early concurrent decoding). This implies AMD ryzen has a new more complex (cache) memory controller. But maybe you referred to Spectre, then OK.

AMD ryzen seems to be more like how security should work (at cost of some speed, but ryzen is impressive), I'm still referring to the Meltdown scenario here.

 

AMD (and ARM) is also affected by Spectre but even that seems to be at a much "lesser" degree of a bug for AMD than intel (according to some sources that I have not verified). A fix for Spectre on AMD ryzen might also be much easier to implement and less performance hitting than intel, and if not fixed ryzen should be harder to attack (again according to some unverified resources).

 

14 hours ago, SSD said:

For sure AMD has made great strides, but there continue to be challenges with the Ryzen and TR CPUs with unRAID.

I must admit I haven't looked into ryzen "flaws and linux/UnRaid compatibility problems". I feared it might not look good.

Or is there anything else you are thinking of?

A short list of incompatibility or flaws would be appreciated (by anyone), but I fully believe you (of course) and really appreciate your advice.

 

I know intel is kind of approved/preferred and tested linux hardware.

 

 

14 hours ago, SSD said:

If you want a troublefree unRAID experience, I would advise Intel vs AMD at this point in time.

+

14 hours ago, SSD said:

I personally would not trade it for an AMD at this point in time.

OK thank you very much. I will keep my intel CPU and Z370 motherboard then. I really appreciate this advice.

 

14 hours ago, SSD said:

The 8700K with its 6 Cores and over 16000 passmark would make a great CPU for unRAID.

Great.

OK so hyperthreading is OK now? I don't know how passmark is measured but is there not a risk of it becoming worse after January OS updates?

Of course we all hope speed drop will be small.

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading again link is only for reference.

So I assume this is considered fixed with intel microcode that rolled out during 2017 + latest UnRaid as mentioned last in the thread (at page 3).

At least for 8700K CPU as I interpret your answer.

Thank you for that clarification too. Awesome.

 

UnRaid v 6.4.0-rc16b has "Early microcode loading support.") according to unRAID OS version 6.4.0-rc16b available.

So you don't even have to update your BIOS to get this new microcode loaded or how should I understand this (assuming you run UnRaid6.4.0 rc16b or later and that the CPU has gotten updated microcode from intel)?

 

[pwm]

9 minutes ago, Alexander said:

Yes but AMD says that ryzen do not leak this cache data (at least not with the Meltdown scenario). Ryzen MMU (Memory management unit) is better protected against access to cache data of other processes even in complex code scenarios using code prediction and early concurrent decoding). This implies AMD ryzen has a new more complex (cache) memory controller. But maybe you referred to Spectre, then OK.

I most definitely referred to Spectre. That's why I started that paragraph with:

19 hours ago, pwm said:

The other is not Intel-specific (Spectre) and even if the initial attack code was written for Intel processors, it affects AMD too.

 

 

But if going back to Meltdown - that vulnerability isn't because Intel has a less complex memory controller, but because they have different behavior for speculative execution. Intel allows a user-space program to perform speculative access to protected memory and then later checks if the access was ok. But then the program can already have tainted cache lines, so when the processor throws away the result of that speculative execution the cache still leaks information that specific cache lines was accessed.

 

One interesting thing here is that the researchers thought only Intel was affected by Meltdown. But ARM has acknowledged that Cortex-A75 also suffers from it, even if not as much as the Intel chips.

 

17 minutes ago, Alexander said:

NAS and VMs are in the worser range maybe even 10-50% and if that proves to be true it is really bad for intel.

For NAS use, you will probably not be able to see any slowdown at all, because NAS functionality is normally hardware-limited by disks, disk controllers and network cards. It's VM and Docker that will see varying degrees of slowdown depending on how often the code needs to jump in/out of kernel functions. Code running in user land isn't affected - it's the transitions between userspace/kernelspace that takes the hit.

 

20 minutes ago, Alexander said:

AMD (and ARM) is also affected by Spectre but even that seems to be at a much "lesser" degree of a bug for AMD than intel (according to some sources that I have not verified).

We currently know very little about the state for AMD and ARM when it comes to the Spectre attack, because the researchers spent most of their time on Intel chips. So they haven't spent all the months on reverse-engineering how the cache and the branch prediction behaves. The danger with that is that that there may come a significant fallout at a later time when they start to really hammer on AMD and ARM chips. Current attacks works on AMD and ARM - but tomorrows attacks may potentially work hundreds or thousands of times faster when the attackers have better decoded how to set the internal state of the branch predictors etc.

 

So right now, all we now is that the majority of servers in this world are running Intel chips. But only the future will tell which chips will have the biggest issues with Spectre.

[Alexander]

OMG what an awesome answer.

Extremely interesting.

 

Excellent, and thank you very much pwm.

[phbigred]

https://youtu.be/JbhKUjPRk5Q

I just posted this in the security forum it may apply to NAS after all if this is verified. 

[pwm]

On 1/9/2018 at 4:06 AM, phbigred said:

https://youtu.be/JbhKUjPRk5Q

I just posted this in the security forum it may apply to NAS after all if this is verified. 

What you can see is that when using the fastest possible SSD using the NVMe interface and doing really small writes, the write performance will hurt significantly. This is because the patches affects the cost of jumping on/out of the kernel. And with 4kB writes, there will be a huge number of writes/second. A Samsung 960 Pro can handle about 2.1 GB/s write speed, and can handle up to 440000 I/O per second. But a normal NAS isn't handling even close to these figures - a normal HDD has a hard time doing even 100 random IOPS.

With larger writes, there are fewer switches between kernel and user space, so less slowdown.

 

SATA-based SSD has lower write speeds which means that there will be fewer kernel calls/second to saturate the drive and so less write slowdown. And HDD write performance would be even less affected, since a HDD has even lower sustained write speeds and extremely much lower random IOPS performance.

 

So for normal NAS use, you should still see quite marginal effect. But Docker or VM that performs large amounts of small writes to a really fast SSD will get hurt, according to the linked benchmark tests. It's programs that performs a huge number of kernel calls that are likely to get hurt.