[fonograph]

All intel cpu made in last 10 years have serious security problem,the only fix is windows update,performance will suffer with up to 40% slowdown.Thats what I have read.

I just bought 8600k cpu,it was deliverrd today,it is still unopened.Should I return it and get Ryzen?

I read that AMD isnt affected but the programers can be lazy and apply the security fix to AMD cpus too to avoid making alternative version specificaly for machines running AMD without the performance slowing fix that only Intel needs.

[flotus1]

These performance drops are "up to xy%".
There are already a lot of benchmarks out there that show negligible performance degradation for a large range of applications. My educated guess is that CFD performance will not be affected. If you want to switch manufacturers due to general loss of trust is a different story though

[Simbelmynë]

Or you could go with Linux and pick an older kernel without the updated block of the security hole.

[ghost82]

I'm interested in this topic too.
At the moment, I would go for not updating my windows 7 sp1 machines (it seems the patch is not yet released at the moment for windows 7 sp1, maybe it will be available tomorrow or in the near future).
KB4056897 is available for win 10 now.

I have also seen some performance charts (pre and post both meltdown and spectre patches) with a core i7 cpu about compressing/decompressing, read/write timing from/to hd, 3d content creation and rendering, simulation in excel, encryption/decryption: none of these operations really affected the performance.
However, I've also seen a chart about performance of a cloud service and there I could see performance degradation.

So, still not sure if these patches will slowdown cfd calculations....

[pbrady2013]

Hi All,

For what its worth we (I work at Pacific ESI) are working with some colleagues at the UTS Faculty of Engineering and IT as we patch our machines. So far in our initial tests we are not getting significant performance hits from from the patches. Now I do stress that these are initial tests and we've started with our test machines but for a dual socket Dell R7910 Xeon E5-2699 v4 with 256GM RAM running RHEL 7.x with both hardware and software patches applied our run times are not that much different. In fact, within the bounds of testing I'd say that there is almost no difference.

See attached for a full graph.

There's a more detailed report on my personal webpage or LinkedIn. I'm happy to post more as we move through the rest of our machines and do a more complete analysis.

[ghost82]

Thank you very much Peter for your valuable reply!

[fonograph]

Originally Posted by pbrady2013

Hi All,

For what its worth we (I work at Pacific ESI) are working with some colleagues at the UTS Faculty of Engineering and IT as we patch our machines. So far in our initial tests we are not getting significant performance hits from from the patches. Now I do stress that these are initial tests and we've started with our test machines but for a dual socket Dell R7910 Xeon E5-2699 v4 with 256GM RAM running RHEL 7.x with both hardware and software patches applied our run times are not that much different. In fact, within the bounds of testing I'd say that there is almost no difference.

See attached for a full graph.

There's a more detailed report on my personal webpage or LinkedIn. I'm happy to post more as we move through the rest of our machines and do a more complete analysis.

Did you just updated Windows? Did you update Bios?

The Windows patch notes mention that just the Windows update isnt enough to protect,Bios must be updated too.The performance hit is cumulative and bigger portion of it comes from the Bios update.

[ghost82]

Originally Posted by fonograph

Did you just updated Windows? Did you update Bios?

It's written in the post:

...with both hardware and software patches...

And also in the linked article:

The machine was patched with both the Dell’s BIOS and RedHat’s OS patches.

[pbrady2013]

Originally Posted by fonograph

Did you just updated Windows? Did you update Bios?

The Windows patch notes mention that just the Windows update isnt enough to protect,Bios must be updated too.The performance hit is cumulative and bigger portion of it comes from the Bios update.

Hi Fonograph,

Minor note: all my CFD boxes are RedHat linux and mostly they are on the seven series, I've a few older that are still on the six series.

OK, now that is a good question though, in this case we'd applied the manufacture's (Dell/Intel) BIOS patches and were testing the effect of turning on and off the RedHat kernel level fixes only. Thinking about this further the better bet would be to:

1. Do a full set of benchmarks with base BIOS and OS
2. Update the BIOS -> benchmark
3. Update the OS -> benchmark

Thanks for the feedback. I've got a whole lot more boxes to run through so I'll post the updates as I get them in. I currently don't have a baseline comparison with the same benchmark for the E5-2699v4.


Cheers,
-pete

[flotus1]

Is there any point in applying only one of the fixes and leaving the OS unpatched?
Because if there is not, I think your testing method is sufficient without 2.

[pbrady2013]

Originally Posted by flotus1

Is there any point in applying only one of the fixes and leaving the OS unpatched?
Because if there is not, I think your testing method is sufficient without 2.

Thanks for the comment. I tend to agree.

What I'll do though is we have more test machines to go through over the next week or so before patching a fleet of boxes in a HPC cluster. We have a variety of machines from E3-1270v3s up to Gold 6126s.

I'll continue to runs benchmarks as we go, with input from these comments, and see what happens. I'll post what I get and there should be some non-CFD results as well if people are interested.

Cheers,
-pete

[pbrady2013]

Thanks go to Matt Gaston at UTS, one of my collaborators, for running this set of benchmarks with CFD-ACE+. His methodology was as per my previous post were he looked at three cases:

1. Base case: BIOS A19, Kernel 3.10.0-514.6.1.el7.x86_64
2. Fully patched (A24, 3.10.0-693.11.6.el7.x86_64) but with RHEL tunables off
3. Fully patched (A24, 3.10.0-693.11.6.el7.x86_64) but with RHEL tunables on.

Further, he ran the benchmarks a few times to look at the repeatability. In the table below "Relative Difference" is simple t(measured)/t(base) and a simple sample standard deviation was used to estimate the spread of the results. For CFD-ACE+ two benchmarks were used:

1. VOF
   1. 1.000 ± 0.841%
   2. 0.984 ± 0.031%
   3. 1.023 ± 0.111%
2. Multi4
   1. 1.000 ± 0.219%
   2. 0.994 ± 0.233%
   3. 1.009 ± 0.253%

Looking at the CFD-ACE+ results, it suggests that for older machines simply applying the newer bios will mitigate the fix and reduced performance hits due to the newer/better microcode. This then does lead to the question of what happens to newer machines which already have the better microcode on them. As I get around to those I'll post results.

In case you are interested similar tests were run for MATLAB (run times inproved across the board) and ANSYS (similar results to ACE) over at my website.

Cheers,
-pete

[Superdude_123]

On our AMD Ryzen 1950x machine, I haven't seen anything worth noting (Linux as OS). I actually found that adding a 3rd and 4th stick of ram had more effect on speed increases than Ubuntu 16.04 updates did in terms potential speed degradation.

[sophiewilson0191]

How Would Spectre or Meltdown Work?

Both exploit types have been reported to be associated with a computing function known as speculative execution. This development allows microprocessors to ‘hold’ some types of information in reserve, in the anticipation that it will be the next piece of data required by the user. This information may come in the form of what code should run next or probable queries; alternatively, it may be of a sensitive nature, for example passwords or card numbers.

Information that is ‘lined up’ in this way may therefore be predicted through inference-based analysis. Executive function is one of many adaptations that promote processing speed and economy over the years, and have been further emphasised by manufacturers responding to demands for ever more responsive and efficient chipsets. However, this has resulted in the potential for attacks on device properties such as executive functions, which are collectively known as ‘side channels’.

For more information visit here.