Windows Updates since December 2017 – Performance Loss!

Topic

New Reply

I have a small but well-tuned Windows 7 x64 Ultimate system that I bought new in 2015.

It’s Haswell-based, a Dell PowerEdge T20 tower system with a Pentium G3220 processor, 8 GB of RAM, and an array of 3 120GB SSDs in RAID 5 arrangement. It serves as an always-on small business server system.

Up to now I have been holding it back at a December 2017 patch level because I have not liked what I have heard and seen regarding the Meltdown/Spectre patches, both from performance AND security perspectives.

Last night, April 25, 2018, I found time to update the system (both BIOS and Windows Update) and I did some well-controlled before vs. after tests.

TLDR: I found:

1. The Meltdown and Spectre mitigations cut HEAVILY into machine performance, precisely in ways you’d feel it most.

2. Disabling just the Meltdown and Spectre mitigations doesn’t bring all the performance back.

No real surprise there – Microsoft said performance loss would happen (remember, these were the same folks who said “Windows 10 is faster” LOL).

I measured more than a 50% loss in some categories of desktop display and disk performance after installing the Dell BIOS update (including microcode) AND the latest Windows Updates!

Disabling the two mitigations – by pressing the buttons along the bottom of the GRC InSpectre tool and rebooting – got back most but not quite all of that performance.

After disabling the mitigations, the fully patched system ran most of its benchmarks as well as before patching, though I was only able to measure a maximum disk throughput of a bit higher than 90% of the pre-patch level with a “workstation” disk access simulation.

A Windows 7 system at the April patch level runs a bit slower than at the December 2017 patch level, even with the mitigations disabled.

Since the disk speed loss is less than 10% I’ll need to think a while about whether I want to return it to pre-January patch level. At the moment I’m leaning toward reverting to get back that performance.

Some screen grabs from the benchmarks are attached.

Edit: Real work follow-up…

A compute and disk intensive job that runs on schedule every day at 7:05am completed this morning in 20 minutes, 48 seconds, taking about a minute and a half longer (108% of the time) than it had been taking before. This is consistent with the degradation measured above via the “workstation” disk access measurement.

DNSListCompiler.bat finished on Sunday, April 22, 2018, 07:24:06.
DNSListCompiler.bat finished on Monday, April 23, 2018, 07:24:31.
DNSListCompiler.bat finished on Tuesday, April 24, 2018, 07:24:12.
DNSListCompiler.bat finished on Wednesday, April 25, 2018, 07:24:11.
DNSListCompiler.bat finished on Thursday, April 26, 2018, 07:25:48.

So far it has run all its jobs without problems.

My final conclusion:

An 8% loss in system performance can be attributed to Windows 7 updates since December 2017 when Spectre and Meltdown mitigations are disabled.

I can’t imagine folks would want their system performance and responsiveness to be as badly degraded as the Meltdown and Spectre mitigations cause right out of the chute. And I can’t imagine ANYONE really wanted that brand new vulnerability, Total Meltdown, added in the mix.

-Noel

10 users thanked author for this post.

MrBrian, Cascadian, AlexEiffel, Ascaris, SueW, HiFlyer, satrow, Elly, Microfix, Mr. Natural

Reply | Quote

Replies

Thank you Noel,

I know a lot of you are clear on the situation but it’s taken me a while. What I am finding is all these patches that Microsoft is pushing are addressing the Meltdown and the Total Meltdown vulnerability. The bios updates are required for the Spectre vulnerability in which there is still no known exploit in the wild.

I would be curious to see if the current version of KB4093118 on its own would address the Meltdown issue on a system with no updates installed prior to January. Apparently the AV registry edit is no longer required.

Since there is still no Spectre in the wild yet. I suppose some could hold off on the bios updates and perhaps avoid the slowdown for a while but still be protected from Meltdown.

I’m still trying to educate myself on this (and quite frankly getting tired of it).

From the trenches, this is Red Ruffnsore signing off. 

Red Ruffnsore

1 user thanked author for this post.

Noel Carboni

Reply | Quote

The breadth of benchmarks is much greater in Windows than in Linux, but your results made me wonder just how much performance impact there would be in Linux, where there is no motive to market Windows 10 or newer Intel CPUs.

I used the GNOME disks utility to benchmark my two SSDs in my desktop PC.  One is a Sandisk 120MB, formatted in Linux EXT4, while the other is a Samsung 840 Pro, formatted in NTFS.  Both of them are connected via SATA 3, and are thus subject to the limitations therein.

For CPU performance, I used HardInfo 0.5.1 System Profiler and Benchmark.  It has six quick CPU tests, none taking any longer than a few seconds to complete, and short tests like that tend to have greater variability from run to run.  Still, the results are what they are!

I ran each test in four configurations.  I used kernel 4.13.0.19 (prior to the Meltdown/Spectre patches), with and without the CPU microcode update (Sandy Bridge i5-2500k @4.6 GHz; microcode update is dated February 2018).  I also tested kernel 4.13.0.38, which has the mitigation patches, with the CPU Microcode update.  Finally, I tested kernel 4.15.0.15 with the CPU microcode update, as 4.15 was supposed to have performance improvements that mitigate most of the performance loss due to the security fixes.

First, the disk tests:

Sandisk SSD, Linux EXT4, average read rate, 10.0 MiB sample size:

4.15.0.15, with MC: 442.1 MB/s
4.13.0.38, with MC: 443.8
4.13.0.19, with MC: 442.2
4.13.0.19, without MC: 443.1

Samsung SSD, Windows NTFS, same test:

4.15.0.15, with MC: 499.1 MB/s
4.13.0.38, with MC: 492.6
4.13.0.19, with MC: 499.7
4.13.0.19, without MC: 505.1

CPU tests:

Fibonacci score was 1.14 seconds in all four tests.  FFT was 0.65 seconds in all four tests.

CPU Blowfish (Seconds, lower is better):

4.15.0.15, with MC: 1.92
4.13.0.38, with MC: 1.99
4.13.0.19, with MC: 1.93
4.13.0.19, without MC: 1.92

This test shows a performance loss of ~3.6% in the patched kernel, which was fully mitigated in the patched and more optimized 4.15 kernel (if the numbers are to be believed).

CPU Cryptohash, MiB/s, higher is better:

4.15.0.15, with MC: 815.43*
4.13.0.38, with MC: 829.14
4.13.0.19, with MC: 802.23
4.13.0.19, without MC: 815.14

* I reran the test and saw a score of 830.85, demonstrating the variability possible from test to test.  I would guess that all of these are functionally a tie.

CPU N-Queens (Seconds, lower is better):

4.15.0.15, with MC: 3.35
4.13.0.38, with MC: 3.39
4.13.0.19, with MC: 3.40
4.13.0.19, without MC:3.37

These are all so close that it is difficult to tell whether the differences have any meaning.  Even so, any performance loss that may have been introduced by the microcode update shows as being mitigated by the optimized kernel.  That’s only if these numbers are to be taken at face value.

FPU Raytracing (Seconds, lower is better):

4.15.0.15, with MC: 2.89
4.13.0.38, with MC: 2.93
4.13.0.19, with MC: 2.79
4.13.0.19, without MC: 2.72

This tests the floating-point unit of the CPU (formerly called a “math coprocessor” when it used to be a separate, optional chip as it was in the 386 days and prior).  This test showed the kind of results we’d been led to expect… the best performance was from the pre-patched kernel without the microcode update.  The pre-patched kernel with the microcode update was a tiny bit worse, while the patched kernel with the microcode update showed a more significant performance loss.  The patched 4.15 kernel that was supposed to mitigate some of the performance loss did in fact do so, but the result was still slower than the pre-patched result.

None of the tests showed a huge advantage for any one configuration.  It’s possible that the nature of the tests was insufficient to show the performance differences.  I’d much prefer a more comprehensive test like CrystalDiskMark for the disk performance, but I do not know of such a test for Linux.

 

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

3 users thanked author for this post.

MrBrian, AlexEiffel, Noel Carboni

Reply | Quote

Has an initial, short duration performance loss been attenuated over the course of a week?

I do not have nearly the quantity nor quality of data to support or question the well documented cases presented here. I am not paid a salary to administer a fleet of clients nor have a proprietary interest in maximizing a particular system. My use of operating systems floats the blurry line between business machine and personal communication equipment. And when the hour of day comes that I must set aside the chase for a dollar and turn my attention to concerns of homelife, it becomes very difficult to insert the need for additional research for unlikely gain.

Through the course of mitigations since 01JAN2018 or thereabouts, I had not seen significant impact to performance. I considered myself lucky to be using an old AMD processor set that did not make use of some of the early mitigations. And I chose not address other vulnerabilities for most of this year. Last week, I brought this laptop in line with the GroupA protocol outlined in Woody’s most recent relevant article.

Immediately I saw performance drop in accord with these observations above, and accepted the new normal as a necessary burden of the new times, because I do not push the limits of capability. While I have noticed momentary glitches when many demands coincide, the aspect of operation I see most is available resources at idle. There have been five shutdown cycles in the week, because I loosely follow an old routine of daily power cycles but do not stress absolute compliance. After each start, following a brief maintenance routine, the observed demand on CPU use and physical memory assigned has been attenuating a bit, every day. Now a week later, I see values only slightly higher than the long established normal levels I had been accustomed to. The trend suggests it may be in familiar range by Sunday.

Apologize for the lack of hard numbers to hang a qualified statement onto. I believe that even if I took the time to track and report those, they are less meaningful in comparing different instances; it is the downward trend that is significant.

So I wanted to present the observation of a trend over time, to see if there are similar observations in systems with supporting data to make hard value comparisons.

Reply | Quote