I have done that too. With the simple 9.5 benchmark (using R10) I it stops at 1minute and 35seconds. But I have overclocked my my 3560k so my latest test before I overclocked and with Reason 9.5then the test stopped at 1:29. Still good benchmark.EnochLight wrote: ↑12 Jan 2018No, it's not scientific enough. Your approach is subjective, and the percentage you're reporting is an estimate at best.. I much would have preferred using a Reason benchmark songfile and have actual points where the song stops playing back in the transport, instead. Again, I do appreciate the information you provided, though!drloop wrote: ↑12 Jan 2018
Well benchmarking Reasonn is as scientific as it can get since the perfromance is application dependent.
"One of my projects I tested have a combination of REs and VSTs. Reason before patch was using roughly 53% maximum, after the patch it uses 57% maximum load. The average load was 51% before the patch, after the patch average load 53%.
Win10and a i5 3570K."
Avarage load performance after the patch is roughly 4% lower
Peak load performance after the patch is roughly 7% lower
Scientific enough
Any performance degradation in Reason on pre-Haswell Windows machines with new MS patch?
- EnochLight
- Moderator
- Posts: 8405
- Joined: 17 Jan 2015
- Location: Imladris
Still confused. Are you saying your song benchmark results were 1 minute and 35 seconds before the patch, but 1:29 after the patch?
You overclocked after patching? Or after? Sorry so many questions - just having a hard time interpreting your text.
Win 10 | Ableton Live 11 Suite | Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD
Overclocked and patch 1:35
Stock speed and before patch 1:29
Stock speed and before patch 1:29
- EnochLight
- Moderator
- Posts: 8405
- Joined: 17 Jan 2015
- Location: Imladris
Thanks. Can you run it again with stock CPU speed and patch?
Win 10 | Ableton Live 11 Suite | Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD
-
- Posts: 275
- Joined: 14 Mar 2017
That's kind of exactly what I was getting at
I know there are a lot of ppl like me, using an old cpu with win7,
and they don't want to lose 10-15% of its performance.
Those should not install the patch, and simply mind their surf behavior, use things like noscript and ublock or similar, AV, ...
and avoid shady sites. In theory those measures should be able to block any attempts anyway.
"Will antivirus prevent an attack?"
"In theory, an up-to-date antivirus program should block any attacks, but in practice they are – according to security experts – extremely difficult to detect.
The good news is that there is no known malware which exploits these flaws. But it is still a good idea to keep your antivirus, operating system and apps up to date.
Don’t forget to be vigilant when clicking on links in emails and on websites to avoid downloading malware in the first place."
https://www.techadvisor.co.uk/how-to/se ... s-3669697/
In any case, here are some more bench results scattered throughout this thread, from ppl with old and new systems :EdGrip wrote: ↑12 Jan 2018I am not worried about malware OR losing DSPs. For my money, life's too short for worrying about whether or not I need to start coming up with a cunning scheme to avoid a Windows update so that I don't lose the power for the 6th instance of VK-2.
I know that's easy for me to say, but yeesh.
https://forums.mydigitallife.net/thread ... 081/page-2
Those that do seek a future workaround for their pre-haswell cpu and Win7 or 8.1 are best to keep checking that forum too,
as it will stay up-to-date on the subject.
-
- Posts: 275
- Joined: 14 Mar 2017
And better solutions are already underway, at least for spectre, Google proves :
https://www.bleepingcomputer.com/news/g ... e-attacks/
https://www.bleepingcomputer.com/news/g ... e-attacks/
-
- Posts: 536
- Joined: 03 Aug 2016
Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least. Would love to hear from more Win7/8.1 users about how they're doing with the patch!
The machine I use for recording and video never really gets online, I don't browse or do any of the other things one would do with a day to day computer.
I'm just tossing this in for those of you that can afford 2 machines, and for those that can't think VM's.
Once your recording (or video editing) box is running the way you want why would you ever update it?
I'm just tossing this in for those of you that can afford 2 machines, and for those that can't think VM's.
Once your recording (or video editing) box is running the way you want why would you ever update it?
because it's shiny with that new car smell
https://soundcloud.com/moneykube-qube/s ... d-playlist
Proud Member Of The Awesome League Of Perpetuals
Proud Member Of The Awesome League Of Perpetuals
-
- Posts: 275
- Joined: 14 Mar 2017
Me too...househoppin09 wrote: ↑14 Jan 2018Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least. Would love to hear from more Win7/8.1 users about how they're doing with the patch!
- EnochLight
- Moderator
- Posts: 8405
- Joined: 17 Jan 2015
- Location: Imladris
Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.househoppin09 wrote: ↑14 Jan 2018Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least.
Win 10 | Ableton Live 11 Suite | Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD
-
- Posts: 536
- Joined: 03 Aug 2016
Judging by the anecdotal reports earlier in this thread and elsewhere, it seems that pre-Haswell Win10 setups are getting very marginal slowdown, if any, in Reason and various other DAWs. In theory, the lack of INVPCID on pre-Haswell chips should make a big difference, but for whatever reason it doesn't seem to be having much effect in practice, at least for audio workloads. The kernel changes made between Win8.1 and Win10 are a different story and seem to be making much more of a difference, which is why the main thing we need at this point is more reports from Win7/8.1 users, regardless of what generation their CPUs are (though pre-Haswell would still be the most telling, of course). It's possible that only the combination of a pre-Win10 kernel and a pre-Haswell CPU will create the conditions that lead to serious performance penalties, but more reports are needed.EnochLight wrote: ↑16 Jan 2018Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.
- EnochLight
- Moderator
- Posts: 8405
- Joined: 17 Jan 2015
- Location: Imladris
If I'm not mistaken, it seems the anecdotal reports also include most users on ASIO audio drivers, which may be something to take into consideration. My worry is that I also use my pre-Haswell-era Windows 10 box as my Plex server as well, and video transcoding is all done on the CPU. But if my Reason projects come out of this largely unscathed, that would be awesome.househoppin09 wrote: ↑16 Jan 2018Judging by the anecdotal reports earlier in this thread and elsewhere, it seems that pre-Haswell Win10 setups are getting very marginal slowdown, if any, in Reason and various other DAWs. In theory, the lack of INVPCID on pre-Haswell chips should make a big difference, but for whatever reason it doesn't seem to be having much effect in practice, at least for audio workloads. The kernel changes made between Win8.1 and Win10 are a different story and seem to be making much more of a difference, which is why the main thing we need at this point is more reports from Win7/8.1 users, regardless of what generation their CPUs are (though pre-Haswell would still be the most telling, of course). It's possible that only the combination of a pre-Win10 kernel and a pre-Haswell CPU will create the conditions that lead to serious performance penalties, but more reports are needed.EnochLight wrote: ↑16 Jan 2018Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.
Win 10 | Ableton Live 11 Suite | Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD
-
- Posts: 536
- Joined: 03 Aug 2016
If you're saying you're worried about the video transcoding taking a performance hit from the patch, you can probably stop worrying about that. All the benchmarking I've seen has made a point of looking at video encoding workloads and has concluded that they're not affected to any significant degree.EnochLight wrote: ↑17 Jan 2018If I'm not mistaken, it seems the anecdotal reports also include most users on ASIO audio drivers, which may be something to take into consideration. My worry is that I also use my pre-Haswell-era Windows 10 box as my Plex server as well, and video transcoding is all done on the CPU. But if my Reason projects come out of this largely unscathed, that would be awesome.
-
- Posts: 275
- Joined: 14 Mar 2017
If you're using an older cpu with Win7, here's a simple trick to have the patch installed
without suffering from the 'potential' performance loss, at least while making music.
It involves disabling a registry key when you make music, and enabling it it when doing 'online' business.
1. Install the Windows patch (KB 4073578)
2. Download the following file : https://www.mediafire.com/file/96dd85p1 ... egKeys.zip
It contains two .reg files to enable/disable the M$ fix.
In both cases you need to reboot to apply the registry change.
3.When doing music, first double-click the 'Disable Fix.reg', clear all browser cache and reboot.
Just make sure to stay offline while producing. A healthy workflow anyway...
4.When done producing, double-click the 'Enable Fix.reg' and clear browser cache, reboot.
Best case scenario is that you also clean the file cache and temp files upon every reboot
(singling out the temporary files you actually downloaded too).
If you're into scripting, you can also do a simple script or batch that automates both the reg changes and browser/file cache deletion in one go...
There is now also a program that basically does the same thing as the registry tweaks :
https://www.grc.com/inspectre.htm
Clearing the browser cache is important (best before and after each browsing session), because the malware prone to be released at some point (note that there still isn't any as of yet) would logically focus mostly on browser activity and would inject itself through things like ads and other 'lucrative' js uses to infect a home networked system. Keeping the cache clear before and after each session, combined with only disabling the fix during 'offline' sessions massively reduces the risk of infection and data to be 'read' by the malicious code, even when it is active on your system:
Whenever you're online the patch is active and speculative execution is halted, so the malicious code, 'if' present on your system, will not be able to find any speculative 'secrets' at all. It will be useless, even when installed on your system.
Whenever you're offline with the patch disabled, no malware can get on your system, and if present on your system cannot communicate outside of the pc even with speculative execution enabled and vulnerable for the length of that session.
Combined with a blank browser (and file) cache per session, the risk becomes very minimal.
Since other affected hardware like NVIDIA cards, and most software like AV apps and big names like Google are being mitigated aswell by the vendors, the most obvious and most vulnerable vector for Meltdown and Spectre would continue to be for the most part the browsing habits of the user.
Making sure that you start and end every online session with a blank browser cache
(read: ALL history/cookies/saved sessions&passwords/...deleted),
then whenever you disable the fix and STAY OFFLINE until you enable it again,
It would greatly reduce the risk of actual information theft through infection.
This assumes that you've taken care off all driver and application updates necessary to their latest versions,
and that you don't install any malware or visit sites prone to be infected by it in the first place.
Clean habits produce clean results.
Until better solutions come about this is about the safest way to handle the fixes on old cpu's
while still benefiting full performance during music sessions (or other offline cpu-heavy tasks).
There is already 'Retpolin', developed by Google and already implemented in Linux, that mitigates
all three flaws without any performance loss. Over time it will be implemented by other vendors too (perhaps M$ too ?).
Then it is already known also that older motherboards CAN have their BIOS fixed with the microcode,
although we would have to do it ourselves, and M$ would have to release the actual microcode.
By converting then copying/pasting the microcode into the BIOS rom (there is a specific procedure for it)
it would be a fairly easy process not unlike a BIOS update. Guides for this will eventually become public,
and the way things are going, it will be rather soon than late...
The reason for there still not being any official benchmarks for pre-haswell cpu's on Win7/8.1 is because
there still aren't any official bios updates available for those correlating motherboards,
and so the actual fix with only the M$ patch is still but half complete.
I'll see if I can do some tests on my own 'old' system in the upcoming days/weeks.
I expect losses of between 10-30%...even more for 4K I/O.
I have installed the patch, since it can still be disabled when desired.
It is a Lynnfield on 8gb ram and win7.
without suffering from the 'potential' performance loss, at least while making music.
It involves disabling a registry key when you make music, and enabling it it when doing 'online' business.
1. Install the Windows patch (KB 4073578)
2. Download the following file : https://www.mediafire.com/file/96dd85p1 ... egKeys.zip
It contains two .reg files to enable/disable the M$ fix.
In both cases you need to reboot to apply the registry change.
3.When doing music, first double-click the 'Disable Fix.reg', clear all browser cache and reboot.
Just make sure to stay offline while producing. A healthy workflow anyway...
4.When done producing, double-click the 'Enable Fix.reg' and clear browser cache, reboot.
Best case scenario is that you also clean the file cache and temp files upon every reboot
(singling out the temporary files you actually downloaded too).
If you're into scripting, you can also do a simple script or batch that automates both the reg changes and browser/file cache deletion in one go...
There is now also a program that basically does the same thing as the registry tweaks :
https://www.grc.com/inspectre.htm
Clearing the browser cache is important (best before and after each browsing session), because the malware prone to be released at some point (note that there still isn't any as of yet) would logically focus mostly on browser activity and would inject itself through things like ads and other 'lucrative' js uses to infect a home networked system. Keeping the cache clear before and after each session, combined with only disabling the fix during 'offline' sessions massively reduces the risk of infection and data to be 'read' by the malicious code, even when it is active on your system:
Whenever you're online the patch is active and speculative execution is halted, so the malicious code, 'if' present on your system, will not be able to find any speculative 'secrets' at all. It will be useless, even when installed on your system.
Whenever you're offline with the patch disabled, no malware can get on your system, and if present on your system cannot communicate outside of the pc even with speculative execution enabled and vulnerable for the length of that session.
Combined with a blank browser (and file) cache per session, the risk becomes very minimal.
Since other affected hardware like NVIDIA cards, and most software like AV apps and big names like Google are being mitigated aswell by the vendors, the most obvious and most vulnerable vector for Meltdown and Spectre would continue to be for the most part the browsing habits of the user.
Making sure that you start and end every online session with a blank browser cache
(read: ALL history/cookies/saved sessions&passwords/...deleted),
then whenever you disable the fix and STAY OFFLINE until you enable it again,
It would greatly reduce the risk of actual information theft through infection.
This assumes that you've taken care off all driver and application updates necessary to their latest versions,
and that you don't install any malware or visit sites prone to be infected by it in the first place.
Clean habits produce clean results.
Until better solutions come about this is about the safest way to handle the fixes on old cpu's
while still benefiting full performance during music sessions (or other offline cpu-heavy tasks).
There is already 'Retpolin', developed by Google and already implemented in Linux, that mitigates
all three flaws without any performance loss. Over time it will be implemented by other vendors too (perhaps M$ too ?).
Then it is already known also that older motherboards CAN have their BIOS fixed with the microcode,
although we would have to do it ourselves, and M$ would have to release the actual microcode.
By converting then copying/pasting the microcode into the BIOS rom (there is a specific procedure for it)
it would be a fairly easy process not unlike a BIOS update. Guides for this will eventually become public,
and the way things are going, it will be rather soon than late...
The reason for there still not being any official benchmarks for pre-haswell cpu's on Win7/8.1 is because
there still aren't any official bios updates available for those correlating motherboards,
and so the actual fix with only the M$ patch is still but half complete.
I'll see if I can do some tests on my own 'old' system in the upcoming days/weeks.
I expect losses of between 10-30%...even more for 4K I/O.
I have installed the patch, since it can still be disabled when desired.
It is a Lynnfield on 8gb ram and win7.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 26 guests