With regard to the multicore scheduling: I've read, and don't totally understand, that Sonar can take advantage of multicores, and VST instruments can take advantage of mulitcore scheduling in stand alone mode, but VST instruments cannot take advantage of multicore scheduling when they are running in a host such as Sonar (or any other DAW). So it is possible that the heavy usage you may see on the first core is your VSTs gobbling up the first core.
 
If you check out the NI site for Maschine they discuss this in some detail.
 
Regards,

mmorgan
With regard to the multicore scheduling: I've read, and don't totally understand, that Sonar can take advantage of multicores, and VST instruments can take advantage of mulitcore scheduling in stand alone mode, but VST instruments cannot take advantage of multicore scheduling when they are running in a host such as Sonar (or any other DAW). So it is possible that the heavy usage you may see on the first core is your VSTs gobbling up the first core.

I read those NI threads.  There is a lot of misunderstanding on those threads.  A task doesn't "own" a core per se.  The OS dynamically assigns work to available cores to the greatest extent possible.  The only issue I have seen here is that a SINGLE VST cannot run simultaneously on several cores.  But I believe SONAR puts each VST into its own thread and therefore the OS can put those threads anywhere there is processing available.
 
This has always been a touchy area of OS scheduler design.  Most software people don't understand how important CPU affinity is.  Today's fast processing speeds are only achievable when you keep the CPU pipeline full, and Intel (and other others) have achieved that by designing elaborate hierarchical memory systems to cache instructions  and data flowing into the processing pipeline.  If some software goof causes a task to jump to another core or another CPU, that may seriously interrupt the pipeline.  That can drop performance by 25% or more.  Recent versions of Windows (and presumably Linux and Mac too) tweak the dispatchers to try to keep as much CPU affinity as possible.  That could account for one core running significantly higher than the others.  But that is a good thing, not a bad thing.
 
If this is happening over a sustained period of time, then there is most likely one process that is carrying a huge load.  You can identify that by launching task manager, then clicking on the Resource Monitor button.  Within the resource monitor CPU section, sort processes by CPU usage and the offender should be obvious.

Great stuff, cpalmerlee.   I still don't understand the core imbalances.  I just don't think they've got this down yet, whether it's Sonar or Windows... many of us run oooodles of effects/instruments and I just don't see much of a dynamic distribution across cores/threads.  When I'm running 3 instances of Diva, which is a beast (all in multicore mode) and other current quality vsts the loads would ideally be distributed way more evenly.  5 of my 6 cores are at 10/20 % while core 1 is way up there.  Seems Diva would just be put on a differend core, for each instance but that definately isn't happening as I've tried running just Diva, 2 Divas, then 3 etc... and not much migrates to the other cores.  
 
Hopefully in time it'll get better.  I haven't run into core 1 overloads yet so no real complaints but my 4930 has a lot more headroom than is currently being used.
 
Then again, this is just an ignorant songwriter talkin and I can only hope this is an evolving situation.  

Vastman
 5 of my 6 cores are at 10/20 % while core 1 is way up there.  Seems Diva would just be put on a different core, for each instance but that definitely isn't happening as I've tried running just Diva, 2 Divas, then 3 etc... and not much migrates to the other cores.  

I haven't seen anything that extreme.  Sometimes the CPU numbers can be inflated if multi-process software does what used to be called "spin loops", which is a crude way of doing the interlocks that are necessary for multiple threads to collaborate.  I wouldn't think that would be too common these days, but it might be a possibility.  In such a case, the extra CPU shown under the main core isn't really productive time and would more accurately be shown as waiting.
 
A variation on the spin loop thing is that sometimes when monitoring hardware, you can't depend on receiving interrupts when key events happen.  In those cases, the software may have to frequently (tens or hundreds of times a second) make inquiries against the hardware to determine is something important has happened.  I have no reason to believe that is a big factor in this case.
 
I doubt that is the problem.  It just seems like the main process has more to do than the others.  Things like VSTs naturally end up on their own threads and are therefore eligible to be dispatched on other cores.  But some things aren't as easy to "parallelize" so the effectively end up under the main thread.  Can you identify the process that is taking up the most CPU when this happens?
 

Cpalmerlee, I haven't a clue...just a songwriter watching X3s core/thread meter up top... ur way out of my league! 
 
And, from a practical standpoint, hasn't been a problem yet. I do know multi core is working with DIva as it defaults to single and must be toggled to multi core each time an instance is added. Even when I forget, I'm immediately reminded by the single core hit. Hitting the multi core button eliminates the spike. But overall, the differential btw vote one and the others is high