Mine works best with: 128-256 Buffer + HT OFF + ASIOGuard High
But still not great overall performance from what I am used to on this very same machine.
The key is to experiment with your specific set up. It’s not so polarized as many make it out to be.
How much did this machine cost?
Thats not including the 2200 audio interface!!
Hi. I tried to repeat your benchmark. In my case, the processors are loaded only by 65%. If I turn off the Hyperthreading, then the processors are loaded by almost 100 percent. But more than 33 Halions do not pull in both cases.
Ok nice 
to me this looks like the Asio load need more clock speed, the limit is Cubase in this case.
Try it with VEP on same machine your Workstation is much more powerful.
This can’t be upvoted enough, thanks Nick you shurely saved my day and the performance on two mashines : 
I’m now running 18 synths 64smp buffersize UR44 on Intel Core i7-7800X Skylake-X clocked to 4.5Ghz. I never go above 33% load and I have 2.3ms latency. My system are now rock steady.
This is what I find too. At a buffer of 64 or 32, performance improves when Hyperthreading is disabled but at 128 or above, it’s better with Hyperthreading on. I’m running an AMD 1920x (24 logical cores). Cubase can fully load all 24 cores, given the right type of project.
Any official news on this?
Is this still a Thing? I mean it was announced almost a year ago 
is this even possible to fix by Steinberg/Microsoft?
It appears that Windows Pro for Workstations will provide new, kernel-level optimisations for low latency applications.
The new, relevant power plan is currently available via the Windows insider programme.
Is Steinberg looking into this? Can we have an update on whether Windows Pro for Workstations will affect the performance of Cubase Pro?
Thank you
Something else for consideration…
I read that - page swapping has been a feature of windows since the 16 bit days and still is, that article is a day late and a dollar short. If you don’t want pages swapped out, you need to tell the OS - it’s always been that way. Most applications, even audio ones don’t lock up a lot of memory as it has other negative consequences. Besides, once you hand off data to the an audio driver driver - it’s out of the applications hand.
Agreed, but…I did their test (not sure what it testes exactly) and indeed as they said, on win 7 I never went above 0.20ms and with my win10 partition on the same system I was at 69ms within a few minutes. So there is a problem there. BTW I don’t use myin10 for production only for some testing so I have no idea what the impact is.
Microsoft have optimize latency in Windows 10 great!
28060849 1646258462110354 2066035503652178780 o — ImgBB now we know the problem
Edit: 07.03 The Insider Preview Build 17115 (RS4) never have this problem its better then Win 7.
Cheers
Does Windows Insider Preview Build 17115 (RS4) address the issue of limited thread counts? I’ve moved to Windows 7 and it works well, but would like to move back to Windows 10 (UAudio doesn’t officially support thunderbolt on Windows 7).
Feb 2018 has passed. Can anyone confirm that this is fixed and there is no limit to the number of cores on a CPU?
The first link is about low latency WASAPI, it is irrelevant as we are using ASIO that has lower latency anyway.
The second link is about the memory management that is poorly in the 1709 we hopefully al are running.
This is fixed in the new upcoming win10 release, and very well may be the course of audio interruptions.
This has nothing to do with the limited MMCSS threads that multi-core cpus can handle.
So nothing really indicates that this will ever change, at least MS have not given any statements about it, so this is pure speculation.
So currently there is
I know that #1 is not a problem in Windows 7. Are #2 and #3?
2 yes, 3 no
Microsofts Developer Pete has pointed this:
In Windows 10, the Multimedia Class Scheduler Service was moved from user-mode to kernel-mode, to reduce overhead and improve integration with the kernel thread scheduler.
As a side effect, a per-process limitation of 32 registered threads was introduced. Applications which register a large number of threads in a single process may see MMCSS registration fail in Windows 10, in circumstances where it succeeded in Windows Vista through Windows 8.1.
We are looking at how to address this.
In general, Microsoft recommends the following for developers:
- Prefer using the Windows Real-Time Work Queue API Real-Time Work Queue API (Windows) over manually maintaining a set of dedicated threads.
- Be prepared for MMCSS registration to fail, since MMCSS resources will vary from system to system, and from even from time to time, depending on what other applications on the system are doing.
but Pete linked this Text from password protected Forum (Windows Insiders Developers ), i cannot see in.
