Microsoft's 'Meltdown' Patch Has Little Impact On Storage

[alextheblue]

Look, I think Intel deserves all the legit criticism they get. But Tom's is less downplaying it, and more just being rational. People were screeching about 20-30% performance regressions, but that turned out to be sensationalism. It's better to wait and report the facts, that to whip up a frenzy with clickbait articles that don't have the hard data and legit real-world tests. Real-world performance loss in consumer applications is minimal on the past few Windows versions.

Don't get me wrong, any performance regression is a negative, and this mess is primarily Intel's fault. But the ones who should be the most pissed are companies that rely on non-consumer software that is more substantially impacted. I think this will definitely drum up more business for AMD, especially in the server market, for Epyc. I hope they can keep up with demand.

30% was an estimate but it was more or less accurate. It's worse than 30% in some cases.

See some test results here. Fortnite servers are one example where it breaches 30% performance loss post-Intel Meltdown patch. If]https://imgur.com/a/zYRap#HGvuXnc

If you read my post a bit deeper you'd see I was specifically talking about consumer software. Indeed I said that non-consumer software would be more substantially impacted. The link you posted is for non-consumer server software... the same people I said that SHOULD be pissed and should look into Epyc. Maybe if Epic Games used Epyc server chips, they would be happier.

I was planning on buying Ryzen before all this happened anyway. But do you have any links that show massive performance hits on consumer software? I think for consumers this is overblown... and at the same time for commercial applications it's probably understated (at least by Intel and various cloud providers).

 

[alextheblue]

The issue was not about storage. Using storage to test it will in fact mask the problem since I/O to storage is relatively slow, even with a p900. The issue is kernel calls. A test should run in memory only to measure the CPU performance hit from kernel calls.

Something based off of this maybe:
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/nt-kernel-logger-trace-session

If it's not representative of real-world software, it's just another synthetic. In fact the synthetics storage benches are amongst the ones showing crazy bad results, which just aren't bore out by real-world storage tests. This is mirrored in most if not all actual consumer software.

Server software is a different story and it's UGLY. This WILL damage Intel in servers, and it will damage their reputation in general.

 

[bjornl]

The issue was not about storage. Using storage to test it will in fact mask the problem since I/O to storage is relatively slow, even with a p900. The issue is kernel calls. A test should run in memory only to measure the CPU performance hit from kernel calls.

Something based off of this maybe:
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/nt-kernel-logger-trace-session

If it's not representative of real-world software, it's just another synthetic. In fact the synthetics storage benches are amongst the ones showing crazy bad results, which just aren't bore out by real-world storage tests. This is mirrored in most if not all actual consumer software.

Server software is a different story and it's UGLY. This WILL damage Intel in servers, and it will damage their reputation in general.

You are missing the point or don't know what a kernel call is. The bug/patch have nothing to do with storage. Any test which measures only storage doesn't tell you what the patch did. Might as well be measuring modem baud rate, which could be used to make kernel calls and like storage is limited by the speed of the device and does not measure the impact to kernel calls.

Server impact will be interesting. But the key will be testing things like massive databases not just disk i/o.

 

[alextheblue]

You are missing the point or don't know what a kernel call is. The bug/patch have nothing to do with storage. Any test which measures only storage doesn't tell you what the patch did. Might as well be measuring modem baud rate, which could be used to make kernel calls and like storage is limited by the speed of the device and does not measure the impact to kernel calls.

Server impact will be interesting. But the key will be testing things like massive databases not just disk i/o.

They did the storage testing because people were using synthetic storage benchmarks to "prove" it had a massive impact on consumer usage, at least for storage. It's all in the article. People were out there MAKING it about storage, and showing off charts based on synthetics. So TH disproved the storage concerns with some more realistic testing. Frankly I can't think of any consumer software that would be massively impacted. In real world consumer software, you should not be performing a bajillion kernel calls. Heck even the drivers exist in user space. Show me real consumer software that suffers substantially.

On the other hand, server software will suffer much more substantially, and yeah that needs to be tested. Intel is going to come under some serious fire for this.

 

[bjornl]

You are missing the point or don't know what a kernel call is. The bug/patch have nothing to do with storage. Any test which measures only storage doesn't tell you what the patch did. Might as well be measuring modem baud rate, which could be used to make kernel calls and like storage is limited by the speed of the device and does not measure the impact to kernel calls.

Server impact will be interesting. But the key will be testing things like massive databases not just disk i/o.

They did the storage testing because people were using synthetic storage benchmarks to "prove" it had a massive impact on consumer usage, at least for storage. It's all in the article. People were out there MAKING it about storage, and showing off charts based on synthetics. So TH disproved the storage concerns with some more realistic testing. Frankly I can't think of any consumer software that would be massively impacted. In real world consumer software, you should not be performing a bajillion kernel calls. Heck even the drivers exist in user space. Show me real consumer software that suffers substantially.

On the other hand, server software will suffer much more substantially, and yeah that needs to be tested. Intel is going to come under some serious fire for this.

So the answer is no you don't know what a kernel call is, yet you feel compelled to spam the thread.

 

[Questors]

I kind of get the impression that someone at Tom's might have a lot of stock invested in Intel by the way they've spammed ten or so articles trying to downplay the effects of these "not flaws" in their processors over the last few days. Maybe the effects really will be minimal for most uses, but I'd like to see them take a more objective viewpoint going into tests like this, and actually look for cases where performance is affected.

I would also like to see much more thorough testing being done, including with a variety of storage devices that people actually use (HDD, SATA SSD, NVME) rather than just a $600 Optane drive that may or may not be affected by the patches in the same way that far more common devices and their drivers are. And of course, the tests should be performed with all software and firmware patched (and unpatched), not just the Windows patch alone, and maybe with a variety of builds with hardware from different manufacturers and budget ranges. I don't even see any mention of what hardware configuration was used for these benchmarks, outside of the extremely uncommon storage device from Intel themselves. And PCMark 8 isn't likely to reflect changes that are being made to software to work around this exploit, so for example the disabled performance features in web browsers won't be represented by it. How about also testing things like virtual machines and databases, where it's expected that the performance hit will be larger? This rushed set of benchmarks seems to be here just to dismiss any claims that there could be a problem.

Agreed. Using a cherry picked circumstance is definitely not "real world." I agree with using an Optane drive as a part of the test. However, some HDDs, Hybrid HDDs and SSDs, obviously including NVMe SSDs should have been used also. The basic SSD is highly common in "real world" usage these days.

A more thorough variety of benchmarking should have been done, if the author wants to prove a point.

As other forum users have pointed out, this is a first round of patching, if we believe this the last Windows patch to do with this, we are living in fantasy land. Then there are possible BIOS updates as well.

Also, this article is about the Meltdown patch and does not mention anything about Spectre. I have read several times patching Spectre is going to take more time and effort. It's okay to write articles during the progress, but let's do a final when everything is said and done and the fat lady has finished singing.

 

[thatrevguy]

Please post system specs for these tests; they are meaningless without them. More valuable insight can also be provided by testing this on a pre-Haswell chip lacking INVPCID on Windows. I'm sure there's a huge user base running 2014 and older hardware with Windows.

 

[thuck777]

I am not willing to sacrifice the kind of performance noted for my Windows 7 laptop running a Sandy Bridge i7 CPU. That is stupid, especially given that there really is NO threat. Now that so many systems are going to be updated, there is little reason for any scumbags to try to exploit these vulnerabilities, IMO. From my perspective, the cure is far worse than the disease, especially on older hardware / OS combinations. It just is not worth it. So, I believe Microsoft should make a way to have these patches be OPTIONAL and AVOIDABLE and UNINSTALLABLE. This is crap!