New Win10 LTSB Build with SAC/SAW64 - Initial Testing

[cgrafx]

This is great news! SAW/SAC 64 is moving into hardware alpha testing! Thank you so much for doing this. Good results too. I was starting to lose hope.

I'm very curious about Process Lasso Pro. What is the setup like? Are you pinning SAW/SAC to a single core somehow? If so, are they pinned to the same core - and is it possible to pin them to separate cores? What percentage of the pinned processor (if relevant) are you devoting to SAW/SAC? I've spent a short time on the PL site. I see CPU affinity (under dynamic local mode) but not real-time priority. And their CPU affinity seems to be automatic for whatever it sees as the highest-use threads, rather than by application. But I could easily be getting it wrong.

Great work! And thanks some more!

I looked at a lot of options to get CPU affinity to work. There may be other options, but Lasso was the only one I could get to function reliably.

I've pretty much turned off all the other functions and am really only interested in the CPU pinning and Process Elevation.

I'm not doing anything to the SAW Studio process so it runs as its default process level and can use both CPUs.

Process Lasso lets you easily select CPU affinity and process level and set them to always use those settings. (image below is just to show the Process Lasso interface) You can see the Priority Class and CPU affinity options, where it will either show you the current setting or allow you to always use a particular configuration.

[John Ludlow]

Thanks, Phillip. That picture of the interface makes it really clear how it's organized, except for whether you can choose the core you want to pin the process to. I see that you have worked SAC hard for quite awhile too!

My thought is that PL Pro might make it possible to take advantage of processors with more than two cores by devoting one each to SAC and SAW and letting the others ride herd over everything else. That way, there would be no competition for the two programs that require absolute dominance - but maybe you could still have, for instance, virus protection. I presume that SAC and SAW could still share RAM, but they wouldn't compete, even with each other, for time slices.

I suppose success might depend upon the relative power of the individual cores though. A six core processor that is twice as capable as a two core processor means that each of the six cores in the faster processor is only 2/3 as capable as each of the two cores in the slower processor. So, if you only use one core...

My current studio machine has never had a firewall or an antivirus program, and has never been connected to the Internet - just so that SAW/SAC, in theory, never had to wait. But, there have certainly been times when I wished I didn't have to sneakernet program updates to it, or copy update codes from it. And whenever I plug-in someone else's thumb drive or disk: I always worry about catching something.

I've never been technically clear as to why SAC/SAW have trouble with multi-core processors or, for that matter, why they won't use more of them. If the 'too many cooks in a single-threaded process' theory is truly the reason though, in theory, pinning the programs to their own core (given that that individual core is individually powerful enough) should work. And that would leave other cores free to do everything else. That would just leave sharing peripherals (like disk...) with other processes/cores. I note that there is also an 'I/O priority' option. Maybe that could be pressed into service?

<later...> Oh - also, $36 is cheap if it actually makes thousands of dollars worth of software work great.

[Bob L]

You are still forgetting that all of the cores share the same RAM and only one core gets RAM access at a time... regardless of thread priority... so that is why more cores can end up with less performance... the main engine processing thread can get stepped on by other cores accessing RAM (which they will do all the time generally)... and the problem gets worse with each new OS version... Win 7, 8, 8.1 and 10... each causing more interference than the last.

Bob L

[John Ludlow]

Thanks for weighing in, Bob. I can see your point that there are many competing OS threads that potentially block RAM access. And, there's no denying that more recent versions of Windows have more, essentially daemons, running at any given moment. But, I don't see that, within a given OS version, the number of threads vying for RAM access changes depending upon the number of available cores to run them on. Only one is going to get access at a time, I keep thinking, regardless which core they originate from. The same number of threads will be lined up for RAM access in roughly the same order no matter how they are distributed for processing amongst the cores - so that seems to cancel out since it becomes essentially sequentially single threaded. But, there are other operations that don't involve storage to main RAM that, in theory at least, should be faster in parallel. Overall, in spite of RAM and disk access, there should be fewer clock ticks devoted to the same group of tasks with more cores to run them. Maybe not a whole lot fewer - but some at least and so, no matter what, it at least shouldn't be slower. That's what doesn't make sense to me.

That said, I get that the above is all theoretical and the boots on the ground so far (over a decade...) have seemed to shout emphatically that it's wrong. I've just never been able to put together a cogent story I liked as to why. Something is going on that I'm not considering. But... what?

[Bob L]

When hundreds of threads run on one cpu... thread priority has a say... if the engine thread is the highest priority... no other thread gets a shot... when you introduce more cpus... thread priority NO LONGER wins out over RAM access from other threads... therefore... the engine thread gets stepped on... much more of the time... even from threads at much lower priorities... huge difference as far as achieving low latency stability without dropping buffers. And it gets worse with the newer versions of Windows because of many more background processes as well as the new thread balancing designs which blur thread priorities more and more.

Bob L

[John Ludlow]

Well... that's disappointing. Really surprising too. I would have thought that MS would see the necessity of honoring thread priority between cores. What's the purpose of thread priority for multi-core processors if each core has its own hierarchy? Or, at least, that is what I glean from what you have written. It sounds hopeless then. I presume that Apple and Linux do it differently?

[Bob L]

Not any different to my knowledge... the current system architecture does not seem to have a global system priority that I can find.

Hence the reason why multicores can cause problems with software like SAC fighting for realtime performance on a very non-realtime system.

Bob L

[cgrafx]

I'm haven't fully completed the update to my live rig, but close enough to share some pictures. I still have to swap out the Motherboard on the system to support the higher resolution of the Dell U2515 Monitor (2560 x 1440 resolution) and will be moving to Win10 64 if I don't run into any significant issues with stability. So far testing has been looking good.

I have stable operation with no dropped buffers at 1x32 as long as the display doesn't switch to screen saver. Still trying to track down the exact process that is running so can try playing with CPU affinity and priority settings.

In the mean time, here are some pictures of the updated rig. In the last picture you can see the AVB ethernet jack, which gives me a full split of the audio from all the preamps.

. . .

. . .

[mr_es335]

Philip,

All that I can say is ... "You certainly do very, very, very, nice work!"

[mr_es335]

Philip,

I have stable operation with no dropped buffers at 1x32 as long as the display doesn't switch to screen saver.

... Is an internal monitor screen saver - or the Windows one?