Drfrag Posted February 10, 2017 Share Posted February 10, 2017 syscl, are you shure that is it really needed to have pykeralpha's ssdtprgen ssdt to achieve the same results? I am not using it and my system works just fine only with hwpenabler kext and a script to reload after sleep. I don't have any data corruption and system is very stable anyway. Maybe, patching frequency vectors is all that we need to have correct power management. Looking into the picture you have posted, maximum cpu frequency achieved was about 3Ghz and it should be 3.2Ghz, isn't it? Link to comment Share on other sites More sharing options...
syscl Posted February 10, 2017 Author Share Posted February 10, 2017 i have had HWPEnable=True for awhile on my T460 skylake box (with a proper SSDT PR) so i just assumed this aspect was working!? However, I was using MBP11,1 so may be not working or not 100%? ... i will change to 13,1 and see what is different. how is this HWP value determined and entered? tluck, you can use this to judge if your HWP is enable or not. Note: you need to remove this kext and rebuild kernel cache before you reboot, otherwise this kext will cause your system panic. syscl syscl, are you shure that is it really needed to have pykeralpha's ssdtprgen ssdt to achieve the same results? I am not using it and my system works just fine only with hwpenabler kext and a script to reload after sleep. I don't have any data corruption and system is very stable anyway. Maybe, patching frequency vectors is all that we need to have correct power management. Looking into the picture you have posted, maximum cpu frequency achieved was about 3Ghz and it should be 3.2Ghz, isn't it? Hi @Drfrag, I am pretty sure we need. Actually, once I received my XPS 13 9350 in Nov. 2016, I soon found the HWP power management is incomplete. See the log from my maclog here: 2016-11-23 18:06:07.281075-0600 localhost kernel[0]: (IOPlatformPluginFamily) <IOPlatformPluginFamily`DebugPrint> WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x4e -- power management may be incomplete or unsupported Due to the fact cpu power management was incomplete, AGPM(Apple Graphics Power Management) was not implemented either. Usually, laptop manufactures will protect MSR 0xE2(read only) which wmrsr64 would write value on it to cause kernel panic. If you are lucky enough to unlock MSR 0xE2 lock like Dell Precision M3800 or XPS 9530, then you may not need this kernel patch. BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 4 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. Tune frequency vectors is optional, only when you need more ideal situation then you can tune it to fit your CPU/GPU. I will post injector method latter(which @Sherlocks has proven worked well using my modified version of X86PlatformPlugin.kext like a dummy AppleHDA). syscl Link to comment Share on other sites More sharing options...
slayer2333 Posted February 10, 2017 Share Posted February 10, 2017 BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. I have 3 options in battery and 4 in Power adapter (what is the 5th option supposed to be ? Maybe depends on the hardware ) ? Link to comment Share on other sites More sharing options...
syscl Posted February 10, 2017 Author Share Posted February 10, 2017 BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. I have 3 options in battery and 4 in Power adapter (what is the 5th option supposed to be ? Maybe depends on the hardware ) ? Screen Shot 2017-02-10 at 2.02.39 PM.png Screen Shot 2017-02-10 at 2.02.44 PM.png Screen Shot 2017-02-10 at 2.03.00 PM.png Sorry, my typo, should be 4 options. Thank you for remind, I corrected it. syscl Link to comment Share on other sites More sharing options...
dpassmor Posted February 11, 2017 Share Posted February 11, 2017 Use Clover to active HWP, not the kext. syscl A couple of notes; You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery. Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0: // inject plugin-type on CPU0 to enable GPU power management DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500) { External (\_PR_.CPU0, DeviceObj) External (DTGP, MethodObj) Scope (\_PR_.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" Local0 = Package (0x02) { "plugin-type", One } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } 4 Link to comment Share on other sites More sharing options...
PMheart Posted February 11, 2017 Share Posted February 11, 2017 (edited) A couple of notes; You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery. Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0: // inject plugin-type on CPU0 to enable GPU power management DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500) { External (\_PR_.CPU0, DeviceObj) External (DTGP, MethodObj) Scope (\_PR_.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" Local0 = Package (0x02) { "plugin-type", One } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Have you ever tested your theory? Only add 'plugin-type' == '1' is not enough. At least. X86* will not load. I tested it previously. (Similar to your tiny SSDT, but I used Clover's PluginType and set that to 1.) No. X86* not loaded. You still have to inject APSS, ACST, etc. Otherwise X86* won't load. That's truth. This could be a bug in X86 but anyway. The truth is here. [EDIT] No. For Skylake with HWP enabled in FrequencyVectors we don't need APSS, ACST anymore. Thanks to dpassmor! tluck, you can use this to judge if your HWP is enable or not. Note: you need to remove this kext and rebuild kernel cache before you reboot, otherwise this kext will cause your system panic. syscl Hi @Drfrag, I am pretty sure we need. Actually, once I received my XPS 13 9350 in Nov. 2016, I soon found the HWP power management is incomplete. See the log from my maclog here: 2016-11-23 18:06:07.281075-0600 localhost kernel[0]: (IOPlatformPluginFamily) <IOPlatformPluginFamily`DebugPrint> WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x4e -- power management may be incomplete or unsupported Due to the fact cpu power management was incomplete, AGPM(Apple Graphics Power Management) was not implemented either. Usually, laptop manufactures will protect MSR 0xE2(read only) which wmrsr64 would write value on it to cause kernel panic. If you are lucky enough to unlock MSR 0xE2 lock like Dell Precision M3800 or XPS 9530, then you may not need this kernel patch. BTW, a lot of people say that they have HWP enable, but they ignore whether their power management is fully implemented. A very simple/useful way is open System Preferences -> Energy Saver to see if there's 3 options in Battery and 5 4 options in Power Adapter. More accurate way you need to open ioreg to search AGPM and X86PlatformPlugin, use kextstat to list all cpu/gpu relate kexts. Tune frequency vectors is optional, only when you need more ideal situation then you can tune it to fit your CPU/GPU. I will post injector method latter(which @Sherlocks has proven worked well using my modified version of X86PlatformPlugin.kext like a dummy AppleHDA). syscl The dummy X86PlatformPlugin will work. I can confirm it here as well. Edited February 11, 2017 by PMheart Link to comment Share on other sites More sharing options...
dpassmor Posted February 11, 2017 Share Posted February 11, 2017 Have you ever tested your theory? Only add 'plugin-type' == '1' is not enough. At least. X86* will not load. I tested it previously. (Similar to your tiny SSDT, but I used Clover's PluginType and set that to 1.) No. X86* not loaded. You still have to inject APSS, ACST, etc. Otherwise X86* won't load. That's truth. This could be a bug in X86 but anyway. The truth is here. Yeah, I'm testing it as we speak, and have been for several days. All that's necessary is plugin-type. bash-3.2# cd /Volumes/EFI/EFI/CLOVER/ACPI/patched/ bash-3.2# iasl SSDT-PR.aml Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20161210-64(RM) Copyright (c) 2000 - 2016 Intel Corporation Binary file appears to be a valid ACPI table, disassembling Input file SSDT-PR.aml, Length 0x95 (149) bytes ACPI: SSDT 0x0000000000000000 000095 (v01 APPLE CpuPm 00006500 INTL 20160422) Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Found 1 external control methods, reparsing with new information Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: SSDT-PR.dsl - 1180 bytes bash-3.2# cat SSDT-PR.dsl /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20161210-64(RM) * Copyright (c) 2000 - 2016 Intel Corporation * * Disassembling to symbolic ASL+ operators * * Disassembly of SSDT-PR.aml, Fri Feb 10 20:26:13 2017 * * Original Table Header: * Signature "SSDT" * Length 0x00000095 (149) * Revision 0x01 * Checksum 0xE1 * OEM ID "APPLE " * OEM Table ID "CpuPm" * OEM Revision 0x00006500 (25856) * Compiler ID "INTL" * Compiler Version 0x20160422 (538313762) */ DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500) { External (_PR_.CPU0, DeviceObj) // (from opcode) External (DTGP, MethodObj) // 5 Arguments (from opcode) Scope (\_PR.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" Local0 = Package (0x02) { "plugin-type", One } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Link to comment Share on other sites More sharing options...
PMheart Posted February 11, 2017 Share Posted February 11, 2017 (edited) Yeah, I'm testing it as we speak, and have been for several days. All that's necessary is plugin-type. bash-3.2# cd /Volumes/EFI/EFI/CLOVER/ACPI/patched/ bash-3.2# iasl SSDT-PR.aml Intel ACPI Component Architecture ASL+ Optimizing Compiler version 20161210-64(RM) Copyright (c) 2000 - 2016 Intel Corporation Binary file appears to be a valid ACPI table, disassembling Input file SSDT-PR.aml, Length 0x95 (149) bytes ACPI: SSDT 0x0000000000000000 000095 (v01 APPLE CpuPm 00006500 INTL 20160422) Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Found 1 external control methods, reparsing with new information Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) Parsing completed Disassembly completed ASL Output: SSDT-PR.dsl - 1180 bytes bash-3.2# cat SSDT-PR.dsl /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20161210-64(RM) * Copyright (c) 2000 - 2016 Intel Corporation * * Disassembling to symbolic ASL+ operators * * Disassembly of SSDT-PR.aml, Fri Feb 10 20:26:13 2017 * * Original Table Header: * Signature "SSDT" * Length 0x00000095 (149) * Revision 0x01 * Checksum 0xE1 * OEM ID "APPLE " * OEM Table ID "CpuPm" * OEM Revision 0x00006500 (25856) * Compiler ID "INTL" * Compiler Version 0x20160422 (538313762) */ DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500) { External (_PR_.CPU0, DeviceObj) // (from opcode) External (DTGP, MethodObj) // 5 Arguments (from opcode) Scope (\_PR.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" Local0 = Package (0x02) { "plugin-type", One } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } I see... But weird. For me the APSS, ACST are still needed. Or (Only injecting plugin-type == 1) X86* won't load... [EDIT] I guessed that that bug had been fixed. Fabulous. Or for Skylake with HWP we don't need the redundant APSS, ACST, that's all HWP can do... In any case, I think APSS ACST are still needed for the older platforms. Edited February 11, 2017 by PMheart Link to comment Share on other sites More sharing options...
dpassmor Posted February 11, 2017 Share Posted February 11, 2017 I see... But weird. For me the APSS, ACST are still needed. Or (Only injecting plugin-type == 1) X86* won't load... Try my SSDT. The Clover PluginType option doesn't do anything, as far as I can tell. Link to comment Share on other sites More sharing options...
PMheart Posted February 11, 2017 Share Posted February 11, 2017 (edited) Try my SSDT. The Clover PluginType option doesn't do anything, as far as I can tell. Sorry I forgot to tell. I also tested a tiny SSDT at that time but without calling DTGP(). But I don't think it's actually related to that. BTW also check my edit at #33 [EDIT] DefinitionBlock ("", "SSDT", 1, "APPLE ", "CpuPm", 0x00021400) { External (_PR_.CPU0, DeviceObj) Scope (\_PR.CPU0) { Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x02) { "plugin-type", One }) } } } This is the tiny SSDT I used in the past. Which made no difference. X86* won't load for my Ivy Bridge hack. For Skylake with HWP enabled we just need this tiny SSDT! Fabulous. Edited February 11, 2017 by PMheart 1 Link to comment Share on other sites More sharing options...
syscl Posted February 11, 2017 Author Share Posted February 11, 2017 A couple of notes; You no longer have to use Clover or HWPEnabler to enable HWP. If X86PlatformPlugin is loaded with a model identifier that supports HWP (MacBook9,1, MacBookPro13,x) the OS will enable HWP, and keep it enabled after sleep. Not only that, but the OS will dynamically manipulate the HWP request values depending on load and whether the system is on AC or battery. Also, I don't believe it is necessary to use a full SSDT generated by ssdtPRGen, it should be sufficient to use one that just sets the plugin-type property on CPU0: // inject plugin-type on CPU0 to enable GPU power management DefinitionBlock ("ssdt_pr.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00006500) { External (\_PR_.CPU0, DeviceObj) External (DTGP, MethodObj) Scope (\_PR_.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Debug = "Writing plugin-type to Registry!" Local0 = Package (0x02) { "plugin-type", One } DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } I've tried this method through Clover's Plugin Type == One, but still no full power management: lost X86PlatformPlugin to load. Actually, there's already plugin type == one in SSDT generated by ssdtPRGen.sh Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store ("Method _PR_.CPU0._DSM Called", Debug) If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x02) { "plugin-type", One }) } I will try your suggestion and let you know. Yes, It did work! Simpler than my method to use ssdtPRGen.sh. I saw you use DTPG method, which may not present on all DSDT from my point of view(you can see my project here, none of them use DTPG method) I suggest use this one(refining from DTPG method) DefinitionBlock ("", "SSDT", 2, "CpuRef", "CpuSsdt", 0x00003000) { External (_PR_.CPU0, DeviceObj) // (from opcode) Scope (\_PR.CPU0) { Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store ("Writing plugin-type to Registry!", Debug) If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x02) { "plugin-type", One }) } } } Thank you, syscl 1 Link to comment Share on other sites More sharing options...
tluck Posted February 12, 2017 Share Posted February 12, 2017 ok switching to MBP13,1 was not enough. editing the Mac-473D31EABEB93F9B.plist to match my CPU was a key step. The default values of 3100/3400 and Freq Vector data did not match my i5-5300u proc. I figured something was wrong as battery was drained really fast yesterday. i noticed that my speed step would only go down to x13 (which matches the default 0D in the freq vector entry) so now i changed frequencies to 2400/3000 and then in the vectors changed 0D to 05 and now much better. i wonder what the rest of the Frequency Vector values mean? questions on this using full SSDT-PR via "pike script" vs bare bones SSDT PR cpuPM etc. what is the best approach? does it conflict in some way? 1 Link to comment Share on other sites More sharing options...
syscl Posted February 12, 2017 Author Share Posted February 12, 2017 ok switching to MBP13,1 was not enough. editing the Mac-473D31EABEB93F9B.plist to match my CPU was a key step. The default values of 3100/3400 and Freq Vector data did not match my i5-5300u proc. I figured something was wrong as battery was drained really fast yesterday. i noticed that my speed step would only go down to x13 (which matches the default 0D in the freq vector entry) so now i changed frequencies to 2300/2900 and then in the vectors changed 0D to 05 and now much better. i wonder what the rest of the Frequency Vector values mean? questions on this using full SSDT-PR via "pike script" vs bare bones SSDT PR cpuPM etc. what is the best approach? does it conflict in some way? Yes as I mentioned, edit frequency vector according to the model you select for your computer is pretty important. MacBookPro13,x can only down to 1.3Ghz which is not ideal even on a real MacBookPro13,x(IMO). We can lower it down, here's the injector I made for my XPS 13, you can use it as a template. I will post this method with more details later on. X86PlatformPluginInjector.kext.zip The first time I've figured out HWP full enable method is by using SSDT-pr generated by ssdtPRGen.sh, but later on @dpassmor reminded me using plugin type == 1 is enough. Less is more is what I propose in this scenario, though APSS will be very likely ignored by X86PlatformPlugin and mach_kernel. syscl 1 Link to comment Share on other sites More sharing options...
tluck Posted February 12, 2017 Share Posted February 12, 2017 cool - so far so good! - injector is working - just dropped my customized Mac-473D31EABEB93F9B.plist into the Resources - switched to "mini-generic" SSDT for CPU above. - turned off generate C/P states via clover. Link to comment Share on other sites More sharing options...
Drfrag Posted February 13, 2017 Share Posted February 13, 2017 Yes as I mentioned, edit frequency vector according to the model you select for your computer is pretty important. MacBookPro13,x can only down to 1.3Ghz which is not ideal even on a real MacBookPro13,x(IMO). How is it on a real MacBook9,1? Does it could not get cpu frequencies lower than 1.2Ghz? And the turbo frequency? Have you reached 3.2ghz on full load? Link to comment Share on other sites More sharing options...
PMheart Posted February 13, 2017 Share Posted February 13, 2017 How is it on a real MacBook9,1? Does it could not get cpu frequencies lower than 1.2Ghz? And the turbo frequency? Have you reached 3.2ghz on full load? The lowest frequency of real MacBook9,1 is x12/1.2 GHz. This is due to the FrequencyVectors. (Check the bit 4, by default it's 0x0C/12 ==> 1200 MHz) Link to comment Share on other sites More sharing options...
tluck Posted February 13, 2017 Share Posted February 13, 2017 FWIW, on my hack system with i5-6300U, AppleIntelInfo shows below - i have never seen it go to down to x4 or to the max at x30?! - i presume this kext tries to obtain all levels - and interesting the max obtained is x29. and perhaps for a split second it got down to x4 - parenthesis i guess indicates current state. CPU Ratio Info:------------------------------------------Base Clock Frequency (BLCK)............. : 100 MHzMaximum Efficiency Ratio/Frequency.......: 4 ( 400 MHz)Maximum non-Turbo Ratio/Frequency........: 25 (2500 MHz)Maximum Turbo Ratio/Frequency............: 30 (3000 MHz) ... CPU P-States [ (4) 5 11 13 14 18 23 29 ] iGPU P-States [ ] ... CPU P-States [ 4 (5) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ] iGPU P-States [ 6 (7) ] Link to comment Share on other sites More sharing options...
Drfrag Posted February 13, 2017 Share Posted February 13, 2017 The lowest frequency of real MacBook9,1 is x12/1.2 GHz. This is due to the FrequencyVectors. (Check the bit 4, by default it's 0x0C/12 ==> 1200 MHz) I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook? FWIW, on my hack system with i5-6300U, AppleIntelInfo shows below - i have never seen it go to down to x4 or to the max at x30?! - i presume this kext tries to obtain all levels - and interesting the max obtained is x29. and perhaps for a split second it got down to x4 - parenthesis i guess indicates current state. CPU Ratio Info: ------------------------------------------ Base Clock Frequency (BLCK)............. : 100 MHz Maximum Efficiency Ratio/Frequency.......: 4 ( 400 MHz) Maximum non-Turbo Ratio/Frequency........: 25 (2500 MHz) Maximum Turbo Ratio/Frequency............: 30 (3000 MHz) ... CPU P-States [ (4) 5 11 13 14 18 23 29 ] iGPU P-States [ ] ... CPU P-States [ 4 (5) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ] iGPU P-States [ 6 (7) ] Did you change "D" to "4" to have 400Mhz as you lower frequency? Just trying to understand if everybody is getting the same results. Link to comment Share on other sites More sharing options...
dpassmor Posted February 13, 2017 Share Posted February 13, 2017 I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook? Did you change "D" to "4" to have 400Mhz as you lower frequency? Just trying to understand if everybody is getting the same results. I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing. Link to comment Share on other sites More sharing options...
tluck Posted February 13, 2017 Share Posted February 13, 2017 @Drfrag - yes - i changed 0D to 04 - then i get 27 CPUPstates - from 400 to 3000. otherwise the lowest speed was step x13. now it idles at step x5 (500) Link to comment Share on other sites More sharing options...
Drfrag Posted February 14, 2017 Share Posted February 14, 2017 FWIW, on my hack system with i5-6300U, AppleIntelInfo shows below - i have never seen it go to down to x4 or to the max at x30?! I saw i5 6300U has a maximum 2.9Ghz on dual core Turbo mode. 3.0 Ghz is for single core. Maybe your tests are just showing dual core performance. I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing. Very interesting. I guess why does Apple keeps this vectors so high. Maybe you are right. Changing this level down won't let any benefits on battery duration. Link to comment Share on other sites More sharing options...
PMheart Posted February 14, 2017 Share Posted February 14, 2017 I think 1.2Ghz is too high. How could a MacBook maintain it's battery for 10hours of iTunes or iBook? Yep I think so. And therefore I lowered it to 0x05 ==> 500 MHz. I found that it seemed that my Core m5 cannot get a lower frequency. The lowest seems to be 500. Also I tuned EPP to 0xC0/192, it's 0x92/146 by default. I am using a MacBookPro13,3 model identifier on my Dell XPS 9550. It has an identical CPU as one of the new MacBook Pro models. These MBPs have a default CPU floor of 1.3Ghz. Now, this is completely anecdotal, but from some rudimentary testing I can't tell the difference in battery life between the default 1.3Ghz, or when I change the frequency vectors to lower it to 800mhz (the floor for the processor itself). Both give me about six hours, and curiously enough, both hover around 1W in Intel Power Gadget when idle. It may be that HWP is doing something in the background to conserve power independently of the observed frequency, I'm curious what other folks are seeing. Yeah I found that sometimes my MacBook9,1 can get a 800 MHz when idling although the FrequencyVectors defines the LFM is 0x0C/12. Could be related to HWP. Very interesting. I guess why does Apple keeps this vectors so high. Maybe you are right. Changing this level down won't let any benefits on battery duration. I guessed that that was for a better performance? Link to comment Share on other sites More sharing options...
xtddd Posted February 14, 2017 Share Posted February 14, 2017 Link to comment Share on other sites More sharing options...
JahStories Posted February 14, 2017 Share Posted February 14, 2017 Pretty interesting stuff I see here! So I noticed some time ago that the cpu was not recognized just using the kext or the clover option for HWP... Right now I'm using the kext, with the script to fix sleep, and frequencies are correctly scaling all this on a mbp13,1 smbios! I tried adding the tiny SSDT, but it seems that I'm still missing AGPM, and I don't have that options under energy panel yet, what should I do too? Edit: I just forgot to add it to the sorted order since I'm using drop oem! Everything working fine here too Thanks again guys! Link to comment Share on other sites More sharing options...
Drfrag Posted February 15, 2017 Share Posted February 15, 2017 my files.zip Didn´t work for me. The patch is not preventing the kernel panic and reboot after trying the tiny ssdt.Maybe I am doing something wrong. Link to comment Share on other sites More sharing options...
Recommended Posts