thanks for the answer! I'm eagerly waiting for a response.
1 of 1 people found this helpful
Bugs1 - Good suggestion, we may do that.
Bugs2 - Ready mode takes over once it's enabled.
Bugs 3&4 - These are known bugs and should be fixed/disabled in the new VBIOS update.
Q1 - Good to know, thank you, we are investigating.
Q3 - Investigating.
Q4 - This is basically a mobile feature-to save battery life, etc, that being in a desktop platform isn't something that's enabled.
Thank you for your response cvare!
Glad to hear about bugfix progress.
About my 3rd Q: The autonomous power mode is "hidden" in Windows 10 aswell.
You have to set the Attribute value to 2 on both Keys here:
HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00\36687f9e-e3a5-4dbf-b1dc-15eb381c6863 (Performance preference policy)
HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00\8baa4a8a-14c6-4451-8e8b-14bdbd197537 (enable/disable autonomous power)
then just hit advanced power options in control panel and check processor power settings.
About Q4: The reason why I asked this is since Microsoft markets the "Modern" Standby for desktop computers aswell. Besides, ready mode by Intel is fundamentally the same as the modern standby supported by Windows.
PS: Another bug: When I enter UEFI within Windows' advanced restart feature, the USB plugged input devices don't respond. But they do work when I enter the VisualBIOS before booting an operating system. For comparison: ASUS VII Gene (Z97), disabled CSM and Legacy USB, entering EFI with Windows' advanced restart without any issues. The NUC is configured the same way; no csm no legacy usb.
Thanks in advance and hope to see a response again
Agreed, took a bit, but we're finally getting there.
Ah, don't know what answers I'll get with a registry edit, but I'll see what I can do.
"Advanced Restart" I think you're talking about the recovery menu? The one where you can select startup repair, or the cmd line, etc? I just tried it and didn't have a problem. Are you using wired, wireless, or bluetooth?
Thanks again for your response.
Luckily, the registry values have a value named "FriendlyName", hope it will avoid any confusion
About advanced restart, I think it is in the recovery menu aswell. I have to distinguish between recovery menu and recovery itself to avoid confusion. For better explanation: "Modern" Settings > Update & security > Recovery > Advanced startup > Restart now > Troubleshooting > Advanced options > UEFI Firmware Settings.
i tried with USB connected Keyboard and Mouse, with Ports behind and front. Both do not respond when restarted into UEFI mentioned the way above. I tried with a Logitech K400r and its unifying receiver, but still the same. About Bluetooth, I would love to see the ability to pair Bluetooth devices inside the UEFI like the Compute Sticks!
1 of 1 people found this helpful
You may have better luck with Intel by calling it "speed shift" or "hardware P-states control".
I can tell you I've checked our Skylake laptops and NUC6 i5 and on Balanced it is enabled both on Battery & AC on Windows 10 Pro, clean. But I don't know if a driver changed them or they were like that by default.
Thank you BigMot!
You are right on hardware p-states since they wrote an article about it (can't find it right now) where the autonomous power mode regulates the p-states.
here are the "Friendly" Names, seen in power options after enabling its visibility via registry:
"Processor performance autonomous mode" (enable/disable)
"Processor energy performance preference policy" (set %)
To be honest I did not know those settings were settable - so that's a big plus - thanks for that! There is an AnandTech and similar showing SpeedShift improvements on Surface 4 on latest Windows 10 builds; search for "Examining Intel's New Speed Shift Tech on Skylake".
There are some other interesting settings in there to make visible - like "performance increase policy" for OS P-state control e.g. set to "idealaggresive" or "rocket" for more responsiveness. But I guess they don't do anything if the hardware manages P-state transitions.
You are right (again ) it was really called SpeedShift! And you are right on the increase policy, it gets ignored after enabling autonomous power mode. Although you can still alter the behaviour of SpeedShift by changing the second registry value I pointed out. (for example 100% doesn't allow the CPU to change to higher frequencies, whereas 0% won't allow the CPU to clock down anymore. I found the setting between 50 - 55% quite enough. There is a response "bug" though, for example if you attempt to playback a video with flash player. The CPU still idles quite low and makes flash player behave really laggy.
Besides of the tests done by Anandtech, I found this article. I will attempt a clean install after the RS1 Update and will check if it gets enabled by default. Maybe I did something wrong when I installed the NUC back then.
Thanks for sharing your knowledge,
That's interesting, this is not how I understood from their datasheets that "Performance Bias" is supposed to work. In addition to your findings I have done some more and I cannot say I'm happy with they way it works. The "old way" seems better to me with clear min/max performance limits in line with multipliers (min/rated/turbo).
This is on an i7-6500U on a laptop but should work similarly on the NUC:
- 33% (default AC)
idles at 1.5-1.6GHz (not as low as 0.8GHz disabled)
- 66% (default Battery)
idles at 0.8GHz (good but was hoping lower)
Turbo 2.5-2.6GHz (so Turbo is limited even though neither Power nor Temperature/PROCHOT was asserted
idles at 1.4GHz
Turbo 2.8GHz (so Turbo limited again)
Personally I think it's pretty weird and will turn it off. Having an arbitrary percentage that governs range within the range we already have min/rated/turbo is not really a replacement. Having yet another Turbo limit in addition to the multitude of limits (Power Short/Long, multiple temps limits, etc.) may just guarantee people will never highest performance - so much for HUGS.
When Disabled - the CPU works as expected:
idles at 0.8GHz sometimes as low as 0.4-0.5 (as expected)
Turbo at 3-3.1GHz, then to rated 2.6GHz
PS. You know - I was wondering why it Skylake laptops don't idle anymore at 0.8GHz; I thought it was some rogue driver that was generating load forcing CPU to ramp up. Now I know it is this. Perhaps it was enabled by recent Windows 10 update but was disabled by default as you've seen.
So you did me a big favour! Now to find out what has enabled it.
One more thing - I did not forget that once Package enters low C-states (e.g. C6/C7+) clock speed "does not matter" so energy consumed would be similar - but it does not stay in those states at idle for 100% of the time.
If at idle it stays at say C6/C7 for 80% and 20% at higher states then clock speed does matter so if it idles at 0.8GHz vs. 1.6GHz then it will consume more power at idle. So it may ramp up faster/more responsive but it seems to me it may well consume more power at idle?
OK so for a NUC this is not relevant but for a Skylake laptop if you're typing all day - so mostly idle - it may well have a big effect on battery life, more responsive or not.
Nice observation and interesting insight!
After the anniversary update (clean install to be precise) I will compare battery runtime on a skylake notebook. I do however notice better reaction time when in autonomous mode on a notebook. But as I wrote before, some processes don't go well (e.g. flash player)
Thanks for sharing your knowledge
What was the OEM cooling solution like? Too much paste, or tape?