Recently discovered Intel CPUs processor design flaw

Find topics on computers, studios and music-related hardware.
User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Sat Jan 13, 2018 6:22 am

eli_lilly wrote:
Sat Jan 13, 2018 2:33 am
The problem isn't Kontakt voices, it's disk IO. In the article you cited, the problem with Kontakt instruments is with voices that use "disk streaming".
The word "voice" is probably used because that's what the user cares about, not disk I/o (even if it would happen to be the actual culprit).

Now as for whether or not the problem really is I/o I think the question is how we know this. You assume it's disk I/o presumably simply because it seems reasonable. However, if disk I/o was the bottleneck for how many voices a given system can play back the wouldn't that bottleneck remain when switching CPUs? If you look at their other charts, like this one, we see large variation on the very same platform(s) with different CPUs. I mean, it's not subtle. On the x299 platform we see a 50+% increase in voices, and same on the x399.

(and it's curious that both the Threadrippers and the i9 CPUs show the same performance increase AND the same core count increase))

Why would a given disk subsystem limit one CPU to 3500 and another to 5460? Wouldn't it be more reasonable to guess that it's the CPUs capacity that's the bottleneck?
eli_lilly wrote:
Sat Jan 13, 2018 2:33 am
DAW and dedicated database servers are ultimately disk IO limited, and in either scenario, if you're at the upper range of utilization you'll feel the impact of the Intel mitigation.
But isn't that inadvertently pointing out the problem being the CPU though? Because to me "upper range of utilization" requires an "upper range" system, i.e. not an i5 CPU but maybe a 7920 or higher.

In other words: If the m.2 drive is capable of a whopping 5460 voices on the x299 platform, wouldn't it have waaaaay more headroom than needed on an i5? The i5 only providing about a fifth of that amount of voices tells me it isn't about the drive i/o it's about the CPU. If the drive is good enough for five times the i/o on an unpatched x299 system why would we see a difference due to bug fixes on the i5? Surely the tiny drop in performance would be far less than the headroom....???
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

KHS
Member
Posts: 362
Joined: Wed Dec 20, 2017 4:05 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by KHS » Sat Jan 13, 2018 12:42 pm

eli_lilly wrote:
Sat Jan 13, 2018 2:33 am

The problem isn't Kontakt voices, it's disk IO. In the article you cited, the problem with Kontakt instruments is with voices that use "disk streaming". In this whole discussions, I've been asked repeatedly why "we" aren't seeing any DAW problems. Well, it's because the "we" who are here in the forums have track counts that top out at 150 (number coming from previous poster disagreeing with me). When you're doing film scoring, however, you're using thousands of tracks (as reported by multiple posters in the main Cubase forum). If you've got thousands of tracks, you've got serious disk IO going on.

Random versus sequential IO depends entirely on where the block is located on disk. Do a punch? No longer sequential. I mean, do you really record all the tracks at once? No aspect of the recording process is nonlinear?

Network throughput is way faster than disk throughput. Disk IO has forever been the slowest aspect of computing until the SSD era, which is recent.

In the database world, no one has seen a real-world "40%" hit. The 30% number that has been bandied about was a very early test of "select 1" under PostgreSQL on Linux, which creates a worse-than-worst-case load.

DAW and dedicated database servers are ultimately disk IO limited, and in either scenario, if you're at the upper range of utilization you'll feel the impact of the Intel mitigation. AKA the long-winded version of my original post.

-E
Sorry to say but you fail to really understand the issue here. You keep assuming it's about specific disk IO when it's not, it's about CPU IO which can be calls to both disk and network and others as well. DAW and server load are far from the same workload as several users in this thread has already told you, which some of them actually work with this stuff daily.
I don't know why you keep going about this when the bottom line is that DAW users are not really affected, well yes they could be by a few percents but that's not something you will notice. Also notice that test from the link above shows biggest impact on low ASIO buffer settings and the higher the buffer the less the impact. Why would this change with buffer settings if this is all about specific disk IO? Well that's because it is not.
Also most users will only run those low buffer settings while tracking and then switch to a more safe lets say 2048 buffer while mixing and producing.
You are running 1000 tracks, well I doubt it but even if you do they are not all playing at the same time and they are not all audio.
Cubase 9.5 Pro - Presonus Audiobox 44VSL - I7-7700K - Gigabyte GTX1070 Xtreme Gaming - 16GB RAM - Gigabyte Gaming 5 Z270 mobo.

User avatar
MrSoundman
Senior Member
Posts: 2178
Joined: Fri Dec 24, 2010 3:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MrSoundman » Sat Jan 13, 2018 1:24 pm

eli_lilly wrote:
Sat Jan 13, 2018 2:33 am
In the database world, no one has seen a real-world "40%" hit.
You can't know this. Not all knowledge is publicly available on the internet.
Windows 10 Pro | Cubase Pro 9.5.50 | WaveLab 9.5.50 | HALion 6.2.20 | Groove Agent 4.2.40 | Midex 3/Midex 8 | x64 only

eli_lilly
Junior Member
Posts: 91
Joined: Wed Oct 21, 2015 9:12 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by eli_lilly » Sat Jan 13, 2018 3:28 pm

KHS wrote:
Sat Jan 13, 2018 12:42 pm
Sorry to say but you fail to really understand the issue here. You keep assuming it's about specific disk IO when it's not, it's about CPU IO which can be calls to both disk and network and others as well. DAW and server load are far from the same workload as several users in this thread has already told you, which some of them actually work with this stuff daily.
I don't know why you keep going about this when the bottom line is that DAW users are not really affected, well yes they could be by a few percents but that's not something you will notice.
The reason I keep coming back to it is due to statements like your first sentence. I have a thorough understanding of the issue. The performance impact is caused when an application has to perform a OS syscall. Prior to the patch, the OS always presented the same page table during syscalls. Now it has to swap back and forth between two page tables.

I work with this stuff daily. I'm sure you're familiar with at least one of the companies I work with - Office Depot, Lilly pharmaceuticals, Toyota, Nine West, TJX, Aldi, and a half dozen others that I'm forgetting. Heck, if you've ever used PHP under Oracle to retrieve a "long" column type, you've actually used code that I've written.

Again, go back to my first message. I clearly said that DAW users would not be affected. Why did you even argue with me then?

-E
Cubase Pro 10, Halion 6, GA4, UR824, Win10, IBM Z800 12 core (HT disabled) 48GB

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Sat Jan 13, 2018 3:54 pm

Can't you just explain how swapping out one CPU for another on the same platform increases the amount of voices when you say it's bound by disk I/O?
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

eli_lilly
Junior Member
Posts: 91
Joined: Wed Oct 21, 2015 9:12 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by eli_lilly » Sat Jan 13, 2018 5:26 pm

MattiasNYC wrote:
Sat Jan 13, 2018 3:54 pm
Can't you just explain how swapping out one CPU for another on the same platform increases the amount of voices when you say it's bound by disk I/O?
The reference to "voices" came from the article that MrSoundman linked to. It's that article that links Kontakt's voice count to disk IO, not me. It wasn't in all cases, either, you'd have to read the article. It's very good.

-E
Cubase Pro 10, Halion 6, GA4, UR824, Win10, IBM Z800 12 core (HT disabled) 48GB

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Sat Jan 13, 2018 8:34 pm

eli_lilly wrote:
Sat Jan 13, 2018 5:26 pm
MattiasNYC wrote:
Sat Jan 13, 2018 3:54 pm
Can't you just explain how swapping out one CPU for another on the same platform increases the amount of voices when you say it's bound by disk I/O?
The reference to "voices" came from the article that MrSoundman linked to. It's that article that links Kontakt's voice count to disk IO, not me. It wasn't in all cases, either, you'd have to read the article. It's very good.

-E
I know where it came from, and I did read the article.

You seem to make a difference between CPU work and "disk IO". Clearly streaming samples off of a drive involves using the CPU to some extent. This is why we can see that the same drive on the same system can yield different amounts of voices.... when we swap out the CPU.

If you agree with that then this difference we see in your writing isn't there and we're all saying the same thing.
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

eli_lilly
Junior Member
Posts: 91
Joined: Wed Oct 21, 2015 9:12 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by eli_lilly » Sat Jan 13, 2018 8:49 pm

I don't really have anything else productive to offer this thread. At this point I'd just be repeating myself.

-E
Cubase Pro 10, Halion 6, GA4, UR824, Win10, IBM Z800 12 core (HT disabled) 48GB

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Sat Jan 13, 2018 8:52 pm

I'm just asking for a clear answer. You could point to the specific sentences you wrote earlier if that's explanation enough. But it's set of pretty simple questions I've asked.
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

KHS
Member
Posts: 362
Joined: Wed Dec 20, 2017 4:05 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by KHS » Sat Jan 13, 2018 9:12 pm

eli_lilly wrote:
Sat Jan 13, 2018 3:28 pm
KHS wrote:
Sat Jan 13, 2018 12:42 pm
Sorry to say but you fail to really understand the issue here. You keep assuming it's about specific disk IO when it's not, it's about CPU IO which can be calls to both disk and network and others as well. DAW and server load are far from the same workload as several users in this thread has already told you, which some of them actually work with this stuff daily.
I don't know why you keep going about this when the bottom line is that DAW users are not really affected, well yes they could be by a few percents but that's not something you will notice.
The reason I keep coming back to it is due to statements like your first sentence. I have a thorough understanding of the issue. The performance impact is caused when an application has to perform a OS syscall. Prior to the patch, the OS always presented the same page table during syscalls. Now it has to swap back and forth between two page tables.

I work with this stuff daily. I'm sure you're familiar with at least one of the companies I work with - Office Depot, Lilly pharmaceuticals, Toyota, Nine West, TJX, Aldi, and a half dozen others that I'm forgetting. Heck, if you've ever used PHP under Oracle to retrieve a "long" column type, you've actually used code that I've written.

Again, go back to my first message. I clearly said that DAW users would not be affected. Why did you even argue with me then?

-E
I keep arguing because in every other post you are saying that DAW users will be affected and the others you say they don't. You also keep saying that DAW workload is the same as servers which is just false information because it is not. You also keep talking about disk IO while it is CPU IO that matters for this.
Cubase 9.5 Pro - Presonus Audiobox 44VSL - I7-7700K - Gigabyte GTX1070 Xtreme Gaming - 16GB RAM - Gigabyte Gaming 5 Z270 mobo.

User avatar
Fly Studio
New Member
Posts: 37
Joined: Sat May 28, 2011 8:28 pm
Location: New Orleans
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by Fly Studio » Mon Jan 22, 2018 12:14 am

MrSoundman wrote:
Fri Jan 12, 2018 11:57 pm
Anything that's near any limit will of course have a problem, but those benchmarks are based on hundreds of Kontakt voices .... how many real-life projects would have, say, 1000 simultaneous Kontakt voices? They indicate approx. 3%-7% of a hit in those extreme cases and for the none at all for many use cases. In the database world, people are seeing anything up to 40% of a hit, which is disasterous, simply no comparision, and the reason is that the disk I/O is of a completely different character (random access read/write with simultaneous high network loads) compared to a DAW (sequential read access with comparatively little or no network activity).
I'm working on Win 7 Pro 64 bit - i7 3770K - 16 GB DDR3 RAM w/ 4 SSDs containing East West Hollywood & Symphonic Orchestras, SD2 & SD3, Pro Drummer, Silk, Ra, etc., Kontakt, Engine Libraries, 8DIO, etc. primarily composing Orchestral / Soundtrack works. I also have 2 UAD-2 cards (Quad & Duo). Was in the middle of reconfiguring system for better IO usage of my libraries when Microsoft released these updates.
I don't have conclusive proof of performance impact on my system, but from everything I've read so far, I seem to fall into the category of a DAW user who would be significantly impacted by the performance drop, based on my CPU, OS and heavy IO streaming.
As for the 'Performance Impact' comments from Intel, MS and others who are:
1) generalizing about what kinds of tasks would be affected,
and
2) Have a vested interest in understating the impact on systems,
I can't go by what they say. They have every reason to downplay the impacts; they haven't released benchmarks on any system lower than 6th gen (I have 3rd gen Ivy Bridge); and DAW usage is rarely if ever addressed on tech forums - they usually talk about gaming, surfing & business applications.
One article I saw stated reassuringly that the typical user (someone who surfs the net, checks their email and does the occasional spreadsheet) won't notice any significant hit. But that begs the question everyone here has thought about at one time or another: How do you get near to 'real-time' performance out of a system that is not designed to perform in real-time? We fork out for the fastest compatible components and make all the proven tweaks we can! And we just wanted to make some music :shock: ..
Now MS, Apple, Intel et al are throwing 'voodoo' 'patches' to mitigate a CPU hardware security problem - a 'problem' that probably wasn't considered to be a problem 5 - 15 years ago (I've seen comments from long time computer geeks saying they knew about this when they were working on DEC systems!).
All this leads me to wonder: If the OS developers took advantage of 'speculative execution' so applications would run faster, they must have had some idea of the security downsides? Or perhaps they never thought about it.
BTW, thanks for the ScanProAudio Link http://www.scanproaudio.info/2018/01/12 ... kstations/, MrSoundman! Good read, but it is still confined to Win 10 on a new system. I guess this will take some time to know the real impact for any given system and how it is used, so I would discourage food fights at the moment. We should stick to straight & verifiable reporting on the performance of each setup as these patches are released and refined.

Note: I am not making a point re the difference between disc IO & CPU utilization; if the patches lower the 'voice count' of Kontakt or Play, it is irrelevant what is causing the performance drop (from my perspective anyway).
  • G
    Cubase 9.5 8.5 7.5 6.5 - Wavelab 9.5 8.5 6 - Halion 6 3
    RME Demeter Hamptone ST MicPre modded by Jim Williams UA-6176
    i7-3770k - Asus Z77 V-Pro - Win 7 Pro SP1 64 bit - 16GB GSkill DDR3 Dram - UAD-2 (6 cores)
    bx DMG Elysia Eventide iZotope Lexicon Overloud PSP Slate Softube Soundtoys SPL UAD Voxengo Waves
    8DIO AAS Arturia EastWest ChrisHein NI Synthology EduardoTarilonte Slate Drums Synthmaster Toontrack UVI VSL

PeppaPig
Member
Posts: 912
Joined: Sat Jan 24, 2015 5:39 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by PeppaPig » Mon Jan 22, 2018 1:27 am

At basic level, the slowdown will be driven by the number of context switches required to perform the task in hand - ie how often does the kernel need to interact with non ring 0 memory addresses - it's not necessarily all about I/O, this is fiendishly difficult to model and there little point trying frankly! A DAW though, as I said before, will perform more context switches per second than most "single user" applications as we are dealing with tens or hundreds of different threads running tens to hundreds of different programs all trying to stream something that lives on disk. Luckily, even when talking about large projects, DAWs demand a fraction of theoretical I/O bandwidth that the platform can deliver - particularly when SSDs are involved. So a small overhead when bits and bytes are being passed in and out of processes through kernel context switching should be tolerable. However, if your processor is somewhere near the limit on any given thread (it only takes one misbehaving thread to kill your ability to render a project cleanly) then this context-switching overhead will push you over the limit.

Of course we have this other issue on Windows 10 with running out of slots for certain plugins, necessitating developers to switch to dynamically linked libraries - these inherently require more context switches to perform the same tasks, ie the code architecture amendments required to fix the slots issue will incur a higher meltdown-mitigation overhead - Interesting times ahead...

As a long-term supporter of the underdog (this is actually my first Intel system for well over a decade!) it's clear that Intel have gained a competitive advantage by playing loose and fast with the fundamentals of privilege segregation - I'm surprised it's taken this long for meltdown to become apparent. Yes Spectre is bad - and difficult to mitigate against - but it's also VERY difficult to exploit - Meltdown is relatively easy to exploit and Intel really should go bust over this - but they've successfully conflated Spectre and Meltdown issues well enough to cloud the fact that they've dropped the ball big time in order to protect themselves from what should be a crap storm of biblical proportions. AMD should be taking out double spread ads pointing the finger firmly at Intel. And Intel, frankly, deserve it. I wonder if the fact that AMD invented the 64 bit x86 architecture in the first place led them to "honour" memory segregation rules more closely where as Intel were looking for performance at any cost - 'scuse the speculation - and the bad pun.
Cubase Pro 9.5, Pro9.0.20. WaveLab 9 EL. UA Apollo Quad FW, UA PCI Octo, UA Satelite Quad, Adam T5V, Golden Audio pre73 DLX, Behringer ADA8200, Intel i7 6850x@4.2Ghz (6C/12T), Asus x99 Deluxe II, AMD 6450 HD, Windows 10 Pro, Samsung 860 and 850 SSDs, 64Gb RAM - Melodyne Studio, Komplete ultimate 11, Halion 6, GA,GA2,GA3,GA4 (+sp), OZ6, OZ7, OZ8 adv, Neutron Adv, BFD3, SoundToys rack, Panorama P1, M-Audio Oxygen, Yamaha YPP55 - outboard: PRO VLAII, Digitech Time machine RDS4000, 1950s Ferrograph Series 5, Mics: AKG C1000S, Rode NT2A and M5 pair, SE2200A, SE X1R, Fame-VT67 (cheap valve U67 clone), Heil PR20&PR22, Behringer Mic2200 used for reamping with a bit of nastiness!

User avatar
Fly Studio
New Member
Posts: 37
Joined: Sat May 28, 2011 8:28 pm
Location: New Orleans
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by Fly Studio » Mon Jan 22, 2018 1:47 am

KHS wrote:
Tue Jan 09, 2018 9:54 pm
The OS patch will only protect against Meltdown. You will need a BIOS update to protect against Spectre.
From what I've read, the patches mitigate Meltdown and Spectre Variant 1; it may even mitigate Spectre Variant 2 (CVE-2017-5715) to an extent but a more comprehensive fix includes a BIOS update.
I also read that it is the Spectre Variant 2 patching that is causing the biggest performance impacts on systems; since the patches can't 'fix' the problem, they are using 'voodoo' techniques to mitigate it; these techniques are causing the performance hits. I can't find the article that broke this down, but when I do, I will post it.
Meanwhile, another tech article indicating the 'voodoo' nature of the initial patches:
Take this for what it's worth:
Initially, we are removing support for SharedArrayBuffer from Microsoft Edge (originally introduced in the Windows 10 Fall Creators Update), and reducing the resolution of performance.now() in Microsoft Edge and Internet Explorer from 5 microseconds to 20 microseconds, with variable jitter of up to an additional 20 microseconds. These two changes substantially increase the difficulty of successfully inferring the content of the CPU cache from a browser process.
https://blogs.windows.com/msedgedev/201 ... 0bjiCll.97
  • G
    Cubase 9.5 8.5 7.5 6.5 - Wavelab 9.5 8.5 6 - Halion 6 3
    RME Demeter Hamptone ST MicPre modded by Jim Williams UA-6176
    i7-3770k - Asus Z77 V-Pro - Win 7 Pro SP1 64 bit - 16GB GSkill DDR3 Dram - UAD-2 (6 cores)
    bx DMG Elysia Eventide iZotope Lexicon Overloud PSP Slate Softube Soundtoys SPL UAD Voxengo Waves
    8DIO AAS Arturia EastWest ChrisHein NI Synthology EduardoTarilonte Slate Drums Synthmaster Toontrack UVI VSL

User avatar
Fly Studio
New Member
Posts: 37
Joined: Sat May 28, 2011 8:28 pm
Location: New Orleans
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by Fly Studio » Mon Jan 22, 2018 2:00 am

PeppaPig wrote:
Mon Jan 22, 2018 1:27 am
At basic level, the slowdown will be driven by the number of context switches required to perform the task in hand - ie how often does the kernel need to interact with non ring 0 memory addresses - it's not necessarily all about I/O, this is fiendishly difficult to model and there little point trying frankly! A DAW though, as I said before, will perform more context switches per second than most "single user" applications as we are dealing with tens or hundreds of different threads running tens to hundreds of different programs all trying to stream something that lives on disk. Luckily, even when talking about large projects, DAWs demand a fraction of theoretical I/O bandwidth that the platform can deliver - particularly when SSDs are involved. So a small overhead when bits and bytes are being passed in and out of processes through kernel context switching should be tolerable. However, if your processor is somewhere near the limit on any given thread (it only takes one misbehaving thread to kill your ability to render a project cleanly) then this context-switching overhead will push you over the limit.

Of course we have this other issue on Windows 10 with running out of slots for certain plugins, necessitating developers to switch to dynamically linked libraries - these inherently require more context switches to perform the same tasks, ie the code architecture amendments required to fix the slots issue will incur a higher meltdown-mitigation overhead - Interesting times ahead...

..it's clear that Intel have gained a competitive advantage by playing loose and fast with the fundamentals of privilege segregation - I'm surprised it's taken this long for meltdown to become apparent. Yes Spectre is bad - and difficult to mitigate against - but it's also VERY difficult to exploit - Meltdown is relatively easy to exploit and Intel really should go bust over this - but they've successfully conflated Spectre and Meltdown issues well enough to cloud the fact that they've dropped the ball big time in order to protect themselves from what should be a crap storm of biblical proportions. AMD should be taking out double spread ads pointing the finger firmly at Intel. And Intel, frankly, deserve it. I wonder if the fact that AMD invented the 64 bit x86 architecture in the first place led them to "honour" memory segregation rules more closely where as Intel were looking for performance at any cost - 'scuse the speculation - and the bad pun.
Looks like you're right about AMD:
This is still primarily an Intel CPU flaw. AMD's official word is that one of the two Spectre variants doesn’t impact them at all, while the one that does is easily resolved by a software update that shouldn’t impact performance in any meaningful way. Variant "three" which is Meltdown, doesn’t impact AMD at all. We've yet to properly test any AMD CPU ourselves, but this is based on the official information we have so far.

That jives with whitepapers I've read; it's Spectre Variant 2 that requires both a software and BIOS patch, and it's these patches that cause the bulk of the performance hits.
https://www.techspot.com/article/1556-m ... e-windows/

As for SSDs, this article only addresses NVMe devices, but I've seen similar results at other sites for SATA SSDs and 4K:
We ran tests that made sense from the perspective of a desktop user and we found there was virtually no impact on gaming performance and no impact for content creators. There were however a few troubling results for NVMe storage devices, mostly impacting 4K read performance. Since then other fellow tech media outlets have published similar findings.
  • G
    Cubase 9.5 8.5 7.5 6.5 - Wavelab 9.5 8.5 6 - Halion 6 3
    RME Demeter Hamptone ST MicPre modded by Jim Williams UA-6176
    i7-3770k - Asus Z77 V-Pro - Win 7 Pro SP1 64 bit - 16GB GSkill DDR3 Dram - UAD-2 (6 cores)
    bx DMG Elysia Eventide iZotope Lexicon Overloud PSP Slate Softube Soundtoys SPL UAD Voxengo Waves
    8DIO AAS Arturia EastWest ChrisHein NI Synthology EduardoTarilonte Slate Drums Synthmaster Toontrack UVI VSL

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Mon Jan 22, 2018 2:39 am

Fly Studio wrote:
Mon Jan 22, 2018 12:14 am
this leads me to wonder: If the OS developers took advantage of 'speculative execution' so applications would run faster, they must have had some idea of the security downsides? Or perhaps they never thought about it.
You've got it backwards. If anything it was Intel specifically that felt it was a worthwhile compromise to gain speed by sacrificing potential security. AMD isn't affected the same way, and the OS manufacturers have nothing to do with the flaw occurring.
Fly Studio wrote:
Mon Jan 22, 2018 12:14 am
We should stick to straight & verifiable reporting on the performance of each setup as these patches are released and refined.
The basic problem with that is that most users don't know how to conduct tests so that a cause of a performance difference can be evaluated. And users would have to consider this - scratch that - would have had to consider this before the patches started rolling out. I think it may be too late now except for the people like those at Scan.
Fly Studio wrote:
Mon Jan 22, 2018 1:47 am
I also read that it is the Spectre Variant 2 patching that is causing the biggest performance impacts on systems; since the patches can't 'fix' the problem, they are using 'voodoo' techniques to mitigate it; these techniques are causing the performance hits.
I don't recall reading or hearing that. As far as I know it is the patching of Meltdown that's causing potentially large performance drops, not the other two.
Fly Studio wrote:
Mon Jan 22, 2018 1:47 am
Meanwhile, another tech article indicating the 'voodoo' nature of the initial patches:
Take this for what it's worth:
Initially, we are removing support for SharedArrayBuffer from Microsoft Edge (originally introduced in the Windows 10 Fall Creators Update), and reducing the resolution of performance.now() in Microsoft Edge and Internet Explorer from 5 microseconds to 20 microseconds, with variable jitter of up to an additional 20 microseconds. These two changes substantially increase the difficulty of successfully inferring the content of the CPU cache from a browser process.
https://blogs.windows.com/msedgedev/201 ... 0bjiCll.97
I think the timing "voodoo" above is actually part of addressing Edge being a path to execute the exploit. Timing is part of making the exploit possible in some cases. Initially the thought was that exploiting these vulnerabilities would have required local access to the computer, but then people figured out some of them could be carried out via software delivered through a browser.
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

User avatar
Fly Studio
New Member
Posts: 37
Joined: Sat May 28, 2011 8:28 pm
Location: New Orleans
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by Fly Studio » Mon Jan 22, 2018 3:03 am

Okay, I am in a position to create an Orchestral Piece using QL Hollywood Orchestra Diamond, 8DIO, Kontakt and a few others streaming from 4 SATA SSDs on a 64 bit Win 7 system & an i7-3770K w 16 GB RAM, and compare the performance before and after the OS patches. It will take a week or two, but at least we will have an apples to apples comparison of Microsoft updates on an older OS & CPU w SATA SSDs - all the variable that are supposedly most affected by these OS updates.

This 'problem' is old, but the articles, benchmarks and patches are new; FWIW, I encourage everyone to stick to your experiences with pre vs. post-patch performance, don't assume everyone uses their DAWs the same way and don't get carried away arguing about exactly where the performance hits take place. It is enough that they potentially do and a question of how it will affect different DAW users with different systems and usage requirements.
If you want insight on the problems and patches, here is a table from an article quoted earlier:

Vulnerability _ CVE ______ Exploit Name _ Public Vulnerability Name _ Windows Changes
Spectre _ _ _ 2017-5753 _ _ Variant 1 _ _ _ Bounds Check Bypass __ _ Compiler change; recompiled binaries now part of Windows Updates & Edge and IE11 hardened to prevent exploit from JavaScript

Spectre _ _ _ 2017-5715 _ _ Variant 2 _ _ _ Branch Target Injection _ _ Calling new CPU instructions to eliminate branch speculation in risky
situations

Meltdown _ _ 2017-5754 __ Variant 3 _ _ _ Rogue Data Cache Load _ _ _ Isolate kernel and user mode page tables

Variant 1 & 3 don't require FW update; 2 does: Silicon Microcode Update ALSO Required on Host: 1) No 2) Yes 3) No

Like I said before, it's the Variant 2 update that causes the bulk of performance hits; it eliminates 'Speculative Execution', which would keep the code for repetitive calculations available (in CPU cache, I presume). Now the Application has to call for instructions every time in 'risky situations'.
https://cloudblogs.microsoft.com/micros ... s-systems/
  • G
    Cubase 9.5 8.5 7.5 6.5 - Wavelab 9.5 8.5 6 - Halion 6 3
    RME Demeter Hamptone ST MicPre modded by Jim Williams UA-6176
    i7-3770k - Asus Z77 V-Pro - Win 7 Pro SP1 64 bit - 16GB GSkill DDR3 Dram - UAD-2 (6 cores)
    bx DMG Elysia Eventide iZotope Lexicon Overloud PSP Slate Softube Soundtoys SPL UAD Voxengo Waves
    8DIO AAS Arturia EastWest ChrisHein NI Synthology EduardoTarilonte Slate Drums Synthmaster Toontrack UVI VSL

KHS
Member
Posts: 362
Joined: Wed Dec 20, 2017 4:05 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by KHS » Mon Jan 22, 2018 7:25 pm

Fly Studio wrote:
Mon Jan 22, 2018 2:00 am

Looks like you're right about AMD:
This is still primarily an Intel CPU flaw. AMD's official word is that one of the two Spectre variants doesn’t impact them at all, while the one that does is easily resolved by a software update that shouldn’t impact performance in any meaningful way. Variant "three" which is Meltdown, doesn’t impact AMD at all. We've yet to properly test any AMD CPU ourselves, but this is based on the official information we have so far.

That jives with whitepapers I've read; it's Spectre Variant 2 that requires both a software and BIOS patch, and it's these patches that cause the bulk of the performance hits.
https://www.techspot.com/article/1556-m ... e-windows/

As for SSDs, this article only addresses NVMe devices, but I've seen similar results at other sites for SATA SSDs and 4K:
We ran tests that made sense from the perspective of a desktop user and we found there was virtually no impact on gaming performance and no impact for content creators. There were however a few troubling results for NVMe storage devices, mostly impacting 4K read performance. Since then other fellow tech media outlets have published similar findings.
Not exactly. AMD has now admitted to be vulnerable to both Spectre variants. Actually AMD seems to have been running dirty by letting Intel taking most of the heat while claiming it didn't affect them.

http://www.tomshardware.com/news/amd-ta ... 36357.html
Cubase 9.5 Pro - Presonus Audiobox 44VSL - I7-7700K - Gigabyte GTX1070 Xtreme Gaming - 16GB RAM - Gigabyte Gaming 5 Z270 mobo.

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Mon Jan 22, 2018 9:11 pm

KHS wrote:
Mon Jan 22, 2018 7:25 pm
Not exactly. AMD has now admitted to be vulnerable to both Spectre variants. Actually AMD seems to have been running dirty by letting Intel taking most of the heat while claiming it didn't affect them.
That's framing the issue in order to make AMD look bad, and doesn't reflect reality very well. There is no "now" in reality regarding what AMD did or didn't say and when that happened...

AMD said from the beginning that it was susceptible to both variants of Spectre, but made the distinction that variant two had a near-zero probability of being exploited in real life. There is nothing about that which equals "running dirty", nothing at all. "Near-zero" means what it means, and it isn't the same as "zero". And that's also why I'm convinced the lawsuit will fail.

It's also a huge difference from implying that both Intel and AMD are equally vulnerable to both. This still is primarily an Intel problem because of Meltdown, and because patching it on Intel's platform hurts performance significantly for some clients - and in as far as I know all of those usage scenarios the same performance hit wouldn't have happened with and AMD platform.
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

User avatar
Fly Studio
New Member
Posts: 37
Joined: Sat May 28, 2011 8:28 pm
Location: New Orleans
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by Fly Studio » Mon Jan 22, 2018 11:15 pm

by MattiasNYC » 21 Jan 2018 19:39

Fly Studio wrote: ↑
21 Jan 2018 18:47
I also read that it is the Spectre Variant 2 patching that is causing the biggest performance impacts on systems; since the patches can't 'fix' the problem, they are using 'voodoo' techniques to mitigate it; these techniques are causing the performance hits.
MattiasNYC:
I don't recall reading or hearing that. As far as I know it is the patching of Meltdown that's causing potentially large performance drops, not the other two.
I read so many whitepapers, discussions, benchmarks, etc. that I don't remember exactly what led me to conclude that, but on one of the tech sites (Tom's Hardware, Tech Republic, Zdnet, etc.), they tried to assess the impact of the patch in question by running a series of SSD benchmarks; they had Reference (pre-patch) results, OS update results and OS & BIOS update results. The only Variant that requires a BIOS microcode update is Spectre Variant 2; that is most likely why I made that assumption. The performance was varied with different test parameters (and the system was brand new with an NVMe SSD). Since the OS updates attempt to mitigate all 3 Variants and ASUS is unlikely to release a BIOS update for my P8-Z77 V Pro motherboard, it is presently irrelevant to me which Variant mitigation strategy is likely to impact performance (if future updates are more targeted to specific Variants, I will revisit the question).

My first comment about OS developers taking advantage of the CPU design was purely speculative, & not an attempt to point the blame at them. Obviously Intel is responsible for the security flaw. I was just wondering if it occurred to the OS developers that taking advantage of the methods in question (e.g. Speculative Execution) might have potential security risks.

I understand that many DAW users have never run a benchmark or would even know how to interpret the results, but some here are up on these things. On one thread, someone said they loaded a 'Stress Test project with 17 instances of Ivory running to compare pre-update & post update results (they saw a very small performance drop, but their OS & CPU were newer, AFAIK); I have screen captures of AAS Benchmarks from each of my SSDs taken at 3 month intervals for comparison, as well as other test results archived. I'm sure others here have similar practices to maximize DAW performance.

BTW, I (apparently) successfully uninstalled both the Cumulative Update KB4056984 & the NET Framework Update 4055532 and regained the performance lost with both my SSDs and other applications (e.g. Desktop operations were slower after the updates - they returned to their snappy state after the rollback); I had just cloned my OS to a new SSD, did benchmarks and DAW tests, then installed the updates - then I read about the possible performance impact, so I had an opportunity to experiment since I had the original OS SSD intact & offline.

I am a musician first & recording - mixing - mastering engineer second; my computer knowledge is long but sporadic and I don't claim to be an expert, so anything that wasn't quoted from a reliable source is speculative to some degree. I.E. I am not here to have a *quiz* contest about these issues. Simply want to find out what people are experiencing, especially when using a massive amount of sample streaming from SSDs, which is the bulk of my work.
Many of my projects reach the upper limit of the 16 GB of DDR3 Dram I have, so any hit in SSD read performance is a big concern for me; if I have to raise the buffers in Play 5, for instance, I will run out of memory with some of the projects I am working on.

I used the term 'voodoo' since software patches are being employed to deal with a low level hardware problem. I also am taking into account the changing landscape of computing; 25 years ago, security was a very different (and largely minimal) concern. I doubt many software (and hardware) designers accurately saw the future trajectory of security and the extent that the 'Net' would have in the future; how many predicted online banking and teams of hackers in foreign countries when DECs were the big boys on campus? And even those DEC CPUs had these basic 'flaws', according to several industry articles I've read.

MattiasNYC, Hope this clarifies my previous post & your point by point response to it. it seems you know more about current OS architecture than I; that's fine by me. I've had my fill of dealing with the tech; and I surely don't mind having an inaccurate statement being corrected. If fact I appreciate it. I could have been more specific and precise, but my post would have been way too long, so my comments were largely 'shorthand'. Besides, this is a 'new' issue and I expect the available info will continue to change for a long time to come.

Fun fact: My band Machine Screw was the first group to multicast a live performance over the Internet (Sept. 7, 1994), using software developed at Cornell and modified - implemented by an Austin ISP. The forerunner of the live podcast I suppose.
  • G
    Cubase 9.5 8.5 7.5 6.5 - Wavelab 9.5 8.5 6 - Halion 6 3
    RME Demeter Hamptone ST MicPre modded by Jim Williams UA-6176
    i7-3770k - Asus Z77 V-Pro - Win 7 Pro SP1 64 bit - 16GB GSkill DDR3 Dram - UAD-2 (6 cores)
    bx DMG Elysia Eventide iZotope Lexicon Overloud PSP Slate Softube Soundtoys SPL UAD Voxengo Waves
    8DIO AAS Arturia EastWest ChrisHein NI Synthology EduardoTarilonte Slate Drums Synthmaster Toontrack UVI VSL

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Tue Jan 23, 2018 12:44 am

Fly Studio wrote:
Mon Jan 22, 2018 11:15 pm
I read so many whitepapers, discussions, benchmarks, etc. that I don't remember exactly what led me to conclude that, but on one of the tech sites (Tom's Hardware, Tech Republic, Zdnet, etc.), they tried to assess the impact of the patch in question by running a series of SSD benchmarks; they had Reference (pre-patch) results, OS update results and OS & BIOS update results. The only Variant that requires a BIOS microcode update is Spectre Variant 2; that is most likely why I made that assumption. The performance was varied with different test parameters (and the system was brand new with an NVMe SSD). Since the OS updates attempt to mitigate all 3 Variants and ASUS is unlikely to release a BIOS update for my P8-Z77 V Pro motherboard, it is presently irrelevant to me which Variant mitigation strategy is likely to impact performance (if future updates are more targeted to specific Variants, I will revisit the question).
I think you're probably right, and that I just remember it incorrectly.
Fly Studio wrote:
Mon Jan 22, 2018 11:15 pm
I understand that many DAW users have never run a benchmark or would even know how to interpret the results, but some here are up on these things. On one thread, someone said they loaded a 'Stress Test project with 17 instances of Ivory running to compare pre-update & post update results (they saw a very small performance drop, but their OS & CPU were newer, AFAIK); I have screen captures of AAS Benchmarks from each of my SSDs taken at 3 month intervals for comparison, as well as other test results archived. I'm sure others here have similar practices to maximize DAW performance.
That's great. I may have misunderestimated my unmisdecomprehension.... I mean... whatever... it's good that you guys check it out and share the results is all I'm saying.
Fly Studio wrote:
Mon Jan 22, 2018 11:15 pm
Fun fact: My band Machine Screw was the first group to multicast a live performance over the Internet (Sept. 7, 1994), using software developed at Cornell and modified - implemented by an Austin ISP. The forerunner of the live podcast I suppose.
A+ for being first.
A+++ for the name "Machine Screw"

:)
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Tue Jan 23, 2018 12:45 am

PS: If I'm sounding grouchy it's a) because people tend to urinate on AMD for not good enough reasons, and more importantly b) because I saw "The Last Jedi" last week and I'm still irritated by what a pile of horse-feces it was.
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

KHS
Member
Posts: 362
Joined: Wed Dec 20, 2017 4:05 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by KHS » Wed Jan 24, 2018 8:11 pm

MattiasNYC wrote:
Mon Jan 22, 2018 9:11 pm
KHS wrote:
Mon Jan 22, 2018 7:25 pm
Not exactly. AMD has now admitted to be vulnerable to both Spectre variants. Actually AMD seems to have been running dirty by letting Intel taking most of the heat while claiming it didn't affect them.
That's framing the issue in order to make AMD look bad, and doesn't reflect reality very well. There is no "now" in reality regarding what AMD did or didn't say and when that happened...

AMD said from the beginning that it was susceptible to both variants of Spectre, but made the distinction that variant two had a near-zero probability of being exploited in real life. There is nothing about that which equals "running dirty", nothing at all. "Near-zero" means what it means, and it isn't the same as "zero". And that's also why I'm convinced the lawsuit will fail.

It's also a huge difference from implying that both Intel and AMD are equally vulnerable to both. This still is primarily an Intel problem because of Meltdown, and because patching it on Intel's platform hurts performance significantly for some clients - and in as far as I know all of those usage scenarios the same performance hit wouldn't have happened with and AMD platform.
AMD didn't issue microcode update at first because it said it had near zero probability and are now issuing the updates because they now admit it's not just a near zero probability. One could argue that AMD was making Intel look bad by saying they had "Near Zero".

It's not mainly an Intel issue anymore. It's not the meltdown patch that will take a hit on your systems performance, it's also not the software patch for Spectre variant 1 that will slow down your system by much. It's the microcode update (meaning BIOS update) for variant 2 that will slow down systems most and that is for both Intel and AMD. Several benching has concluded that with OS patches only, you won't see much performance degradation. But as soon as you apply the microcode update, that's when you will see the most performance hit.
Saying that only Intel are affected are just not correct. No one knows really about AMD yet as it will take some time before the BIOS updates starts to rolling out from Motherboard vendors and thus cannot really be tested until they do.

With that said, it's still not something normal end users will notice.
Cubase 9.5 Pro - Presonus Audiobox 44VSL - I7-7700K - Gigabyte GTX1070 Xtreme Gaming - 16GB RAM - Gigabyte Gaming 5 Z270 mobo.

User avatar
MattiasNYC
Grand Senior Member
Posts: 3549
Joined: Thu Dec 16, 2010 9:27 am
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by MattiasNYC » Fri Jan 26, 2018 12:54 am

KHS wrote:
Wed Jan 24, 2018 8:11 pm
AMD didn't issue microcode update at first because it said it had near zero probability and are now issuing the updates because they now admit it's not just a near zero probability.
Well but that's just your interpretation though. I have not seen AMD say "we no longer think exploitation is near zero probability but is in fact higher, and that's why we're now releasing this". Have you seen them say that or is this indeed just your opinion about it?
KHS wrote:
Wed Jan 24, 2018 8:11 pm
One could argue that AMD was making Intel look bad by saying they had "Near Zero".
Intel was far worse affected, and Intel was far more guilty of muddying the waters to imply that it was affected no more than AMD, ARM or whatever. Just read Intel's statements and compare with AMD. Also, as far as I can tell AMD was absolutely accurate in their initial statements when they made them, and current statements don't seem to contradict the previous ones.
KHS wrote:
Wed Jan 24, 2018 8:11 pm
It's not mainly an Intel issue anymore. It's not the meltdown patch that will take a hit on your systems performance, it's also not the software patch for Spectre variant 1 that will slow down your system by much. It's the microcode update (meaning BIOS update) for variant 2 that will slow down systems most and that is for both Intel and AMD.
Well, but:
KHS wrote:
Wed Jan 24, 2018 8:11 pm
No one knows really about AMD yet as it will take some time before the BIOS updates starts to rolling out from Motherboard vendors and thus cannot really be tested until they do.
so we don't really know if the hit will be of similar magnitude...
Nuendo 7.1.4 / Lynx TWO-B / Windows 10 Pro 64-bit / Ryzen 1700 3.7GHz (oc) / 16GB Corsair Vengeance DDR4@3200MHz / Nvidia GTX 660 / ASUS x370-A mobo/ 500GB WD Blue system drive / Crucial BX100 250GB SSD media / spinners for library/backup ::::: iZotope RX / Phoenixverb Surround / DaVinci Resolve / Faderport / Applied Acoustics UltraAnalog / my pet pony Frank

KHS
Member
Posts: 362
Joined: Wed Dec 20, 2017 4:05 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by KHS » Fri Jan 26, 2018 4:00 pm

MattiasNYC wrote:
Fri Jan 26, 2018 12:54 am

so we don't really know if the hit will be of similar magnitude...
Well, we cannot really know until we see some benchmarks.
Either way it won't really matter for most of us. Numerous benchs have shown little to none performance hit in games and programs used by the normal consumers including DAW usage.
There are some exceptions as you probably now. Running a pre Skylake CPU may show a small performance hit, specially if you are still running Windows 7 or 8.
Cubase 9.5 Pro - Presonus Audiobox 44VSL - I7-7700K - Gigabyte GTX1070 Xtreme Gaming - 16GB RAM - Gigabyte Gaming 5 Z270 mobo.

eli_lilly
Junior Member
Posts: 91
Joined: Wed Oct 21, 2015 9:12 pm
Contact:

Re: Recently discovered Intel CPUs processor design flaw

Post by eli_lilly » Mon Jan 29, 2018 3:05 pm

I found some newish information a few mins ago. Some of you may already know, but it looks like MS has revealed a way to disable both the Meltdown and Spectre (variant 2) mitigations at runtime. This means you don't have to block the patch itself (if you're doing such a thing). The reference is here https://support.microsoft.com/en-us/hel ... ilities-in . The article says this is for Windows 7 and later, these reg keys below seem to be for Windows clients only. Server has some other mechanism or something.

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Of course we all know that performing manual registry mucking should be done only by experts and make sure to image your system prior.

-E
Cubase Pro 10, Halion 6, GA4, UR824, Win10, IBM Z800 12 core (HT disabled) 48GB

Post Reply

Return to “Computer/Studio Hardware & Setup”

Who is online

Users browsing this forum: No registered users and 2 guests