Thank you, TomG for your posts. They gave me the start point for some further research. With this solution you can simply make the "Processor performance core parking min cores" option visible in the "Advanced power management" window, so from the UI you can stop core parking for any power plan, including the new power plans you may customize.
This solution give you the advantage of changing core parking on the fly, without needing to edit the registry again nor the need to reboot: just switch the power plan... even while Sonar is running!, and you'll see the change in the core monitor. Now, what you're doing when changing the ValueMin and ValueMax is setting the valid range of values for every possible Power Plan configuration, but you're not changing the configurations themselves. The actual value is set every time you activate a Power Plan, either by switching them or by switching from AC to DC (battery) power on laptops. For every configuration parameter, every Power Plan has two values, one for AC and another for DC. Some of those parameters, like this one, are just hidden from the Power configuration User Interface.
Since the parameter is hidden, it allways have the default values, 10% for both AC and DC variations in all the Power Plans. Hence, when you change the plan, this 10% value exceeds the range limit you've set for ALL the plans (from 0% to 0%), hence your solution worked. But what we actually want is to tweak the OS by changing the real values, and not it boundaries.
So, instead of setting the ValueMax boundary to 0, we will make this parameter visible from the UI by DELETING the "Attributes" entry under the same key (54533251-82be-4824-96c1-47b60b740d00/0cc5b647-c1df-4637-891a-dec35c318583). The only attribute bit held in the entry is the one telling the UI it is a "hidden" parameter, and by deleting the entry, the parameter will appear as a new option in the "Advanced power management" window, prompting you the ACTUAL % of cores the system is able to park under the current Power Plan, both for AC and DC powering. The range of values you may input is the one defined by the ValueMin and ValueMax, so they must remain with the same values (0 and 64 in hexadecimal/100 decimal).
So, step by step:
1) Go to RegEdit (RegEdt32.exe, even in Win7 x64): 2) Find the key 0cc5b647-c1df-4637-891a-dec35c318583, there are several ones with the Attribute, ValueMin, ValueMax (and othr entries) which are the ones we're interested in. Skip those having AC/DCSettingIndex (which holds the power plans configurations that we will change later from the UI). 3) Delete the Attribute entry. 3.5) ONLY IF YOU ALREADY MODIFIED THE REGISTRY AS SUGGESTED BY TomG: Set the ValueMax again to it original value: 00000064, this is REQUIRED for the current solution to work.
4) Repeat the step 2 as many times as needed to delete those Attribute entries. DO NOT DELETE Attribute ENTRIES FROM OTHER KEYS! 5) Choose a Power Management Plan, or create a new one. 6) Go to the Advanced settings, you will see the "processor performance core parking min cores" parameter. You'll see the default values of 10%. Change them to 0% for either AC, DC or both. 7) Change the Power Management Plan and see the effect on the fly. From now on, if you want to change this setting you don't need to edit the registry anymore :) As for my notebook, I just added a new Power Plan "Music" based on the Max Performance one, then in the Advanced Window i've set the value for AC to 0.
Now, when I swith the plan to "Music" with the notebook plugged to the wall, core parking gets disabled, and it is enabled again should I unplug the notebook or if I switch to any other Power Plan.
Enjoy your Win 7 and your Core iX!
Aditional info: Yesterday I was so excited after finally figuring out this solution that I made the original post at 4:30 AM, sticking to the main problem of disabling core parking. Now I am editing this post to add aditional info that may be usefull for other people.
The Core Parking problem root: Core parking have actually two purposes, the first and most evident one is lower the power consumption and control the chip temperature, and the second one, more subtle is performance: when you have all the processor active, a lot of the background tasks are scattered among them evenly and without a "procesor afinity" (a task configuration making the OS feed the task thread to the chosen processors whenever possible). The same task thread "jumps" from one processor to the next available one, and this "jump" has an overhead because the previous processor state must be transfered to the next one, along with the cached data, with an extra penalty: current processors enhance their performance by prefetching instruction and data ahead to have them ready to execute when needed, but when they face a conditional branch in the program leading to two possible paths, the prefetching effort for one branch could be wasted (since it isn't followed), hence there exist a "jump prediction" mechanism devised to minimize this effort waste. Every time a thread jumps between processors, this prediction effort is completelly wasted. So, whith this task scheduling policy of letting tasks jump between processors the jumping overhead can account for and eficiency lose of 10%, and even 15% with a system running lots of background tasks, and even an "idle" system keeps all the processors working at less than 5%. So, the core parking feature allows the OS to implement a new scheduling policy that feeds most of those background tasks to just one of the processors, thus minimizing this eficiency lose.
Because of this, it is indeed better to leave core parking active whenever possible, because when taking into account the overall system performance it will be improved by up to a 10%... wich in turn frees more resources for the DAW.
Our problem arouses from the fact that this new scheduling policy has side effects that, as for today, are hard to predict, unless the software (the DAW) were way more tightly coupled with the OS.
Actually the core parking feature relies both in the softeare (OS/drivers/firmware) and the hardware (the processors themselves, should they support core parking). In the former side, it is the OS shceduling policy the one that, taking into account the current processing load, chooses NOT to feed a processor with threads, even if the chip istelf were NOT supporting the core parking feature, as to improve the overall system performance. In the later side, the chip itself is unaware of the inmediate future system load as to choose when to park or unpark a processor. Actually, when a processor doesn't get instructions to process, it is stopped, and it is awaked as soon as it faces an instruction to process. This choice is made by an extra "service processor" whose purpose is to orchestate the chip power saving/efficiency features (even more, Core iX chips can decrease or increase the clock ratio for each core in steps of 133 Mhz, according to the peace the instructions are being feed to it processors, and Core i5 and Core i7 can even boost -overclock- a core if needed).
Now, when the OS chooses to park or unpark a processor (disregarding if in the chip it were actually stopped or not), there's a drain of threads forced to "jump" from either the processor to be parked to some other active one, or from the active processors to the processor to be unparked. All of those "jumps", with the forementioned overheads, happens at once, creating a bottleneck that have a huge inmediate and brief inpact in the overall performance. Since the DAW is unaware in advance of the moment the OS will make one of this choices, and moreover, cannot provide the OS task scheduler of windows of oportunities in where to make those choices without inpacting it performance (it is the DAW the one that may predict the inmediate load requirements), it meets an unpredicted sudden drain of processing power leading to the glitches and dropouts.
This is consistent whit what we suffer from core parking: while the load is evenly distributed among the unparked processors, no matter how loaded they were, everything works fine, but while a processor is being parked or unparked, we have glitches and even dropouts. Even more, it is less likely to have a processor parked/unparked with a highly loaded system (e.g. from a big DAW project), than with a low loaded system, where the OS finds more chances to park (and later on unpark) a processor.
Fine tunning Core Parking to be greener without compromising your DAW -specially for those having Core i7, i.e. 8 processors: Core parking is a desired feature even for us: in the ideal scenarios, the overall system performance is more efficient freeing processing power for the DAW to use it, while controlling power consumption and the temperature (a source of noise from the circuits). Now this is pure theory, but I strongly believe this is feasible, and I would like to have a feedback should someone dare to try :) Those having eight or more processors may choose to leave core parking active, but ensuring they have enough processors permanently active to cover their projects processing load requirements. For example, you may choose to have six processors from eight active, grossly speaking, having 4 of them for the DAW to use, and another two for the OS scheduling policy to play with the system load without reaching the point where any of the remaining two processors would have the chance of being unparked. Moreover, having enough permanently active processors, even if other processors were parked or unparked, the DAW should have anough resources to overcome the "drain of threads" bottleneck. So, with the purposed solution, you may have several Power Plans from where to choose different amount of permanently active processors, as to choose among these Power Plans accodringly to the requirements from the projects you're working with. The "Processor performance core parking min cores" option added to the Advanced power management window with this solution SHOULD allow you to pick the amount of cores elegible by the OS to park. This is being shown as percentage from the total amount of processors in your computer. Theoretically, and according to Miscrosoft documentation for this option, should you were picking a value of 50%, you would be enabling the OS to park up to half of your processors. However, there's something odd about this interpretation because the default value (on my system, Win 7 x64 on a Core i3, two physical cores with HyperThreading, i.e. four logical processors) is 10%, and with this value the OS is parking two processors, instead of just one (if that 10% were rounded up to 25%) or none (if that 10% were rounded down to 0%). So it seems it is a matter of tryal and error as to figure out the way this value should be interpreted and used. It'd be great if someone manages to figure it out, to post it :) More performance fine grain -for the most fearest dary ones: DO NOT TRY THIS UNLESS YOU KNOW WHAT YOU'RE DOING, AND WITHOUT CAREFULLY READING THE DOCUMENTATION PROVIDED BY MICROSOFT!!! At least the PMPolicy_Windows.docx and the ProcPowerMgmtWin7 documents should be read. Back to the registry, you will find that the key HKLM\SYSTEM\ControlSet001\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00 holds all the power management available options. Those visible in the Advanced settings window lacks the Attribute entry, while those that are hidden have an Attribute entry with a value of 1. By deleting the Attribute entry (or should some Attribute entry were having a different value, by changing this value substracting the BINARY value of 1 telling it is a "hidden" option) you will make any of those hidden parameters available from the Advanced settings to play with.
There's a LOT of interesting stuff there: the entire new task scheduling policy from Windows 7 and Windows Server 2008 can be exposed to be fine tunned on a per Power Plan basis.
Microsoft DICROURAGES you from doing this, as they say, a mistaken value may severely afect the performance, may render your system unestable -and I suspect you may even fry your processor! So IT IS AT YOUR OWN RISK. A final suggestion to Cakewalk and other software developers: Microsoft documentation claims they choose to change the way the power management settings are arranged in the registry to allow third parties (hardware and software providers) to extend their capabilities and to fine tune the sistem to meet specific requirements.
As an alternative to the purposed solution of exposing to the user an option that Microsoft devised to be hidden, the same control over the power parking feature can be achieved with the line command PowerCFG. With this command you can change the values for the AC and DC powering for the current or for any other Power Plan, and is very likely that if there is a line command to achieve this, there should be an API to do at least the same.
Then an option to solve the core parking problem from within the DAW could be to save the "Processor performance core parking min cores" value from the current plan by queryng it with the PowerCFG command, and then use the command again to set this value to 0 (disabling core parking temporarily), and set the original saved value again when exiting the DAW. This option have the drawback that if the DAW crashes, the current power plan would be altered permanently. Hence other measures would have to be taken to prevent this drawback from happening -or to correct the problem seamesly for the user.
Another option would be to PROVIDE the users (perhaps in the download section of the website) with a Power Plan customized for the DAW. Should the user were having problems with the core parking, it would be a matter of downloading the Power Plan (a .reg file), combining it in the registry (double click on the .reg file) and choose the new Power Plan when using the DAW.
Regards!