DPCIManager 1.5 Open Beta

[OSXGeek]

@SJ

View attachment 46987

Those numbers in pic are P-States for my LGA775 Core 2 processor. Actually I'm little bit confused with P-States, I mean what I read from wikki(IBM) pages is, higher P-States means Lower CPU performance and lower P-States means higher CPU load/performance

But here on my 10.8.2, when the system is idle the Current P-State shows 29 (lowest P-State) and on full CPU load P-State shows 40 (highest P-State). According to wikki pages isn't that the reverse order it should be working?

 

[SJ_UnderWater]

P-States in this case is a bit of a misnomer, because they don't correspond to P States like P0, P1, etc. What MSRDumper and other tools call "states" are really just the current CPU multiplier. Without overclocking, state 40 should correspond to 4.0GHz on a Core i CPU.

 

[OSXGeek]

P-States in this case is a bit of a misnomer, because they don't correspond to P States like P0, P1, etc. What MSRDumper and other tools call "states" are really just the current CPU multiplier. Without overclocking, state 40 should correspond to 4.0GHz on a Core i CPU.

The processor I own is Core 2 Duo Family E4500 @ 2.2GHz , 2MB Cache

CPU Multiplier is 11x (from Bios)

It has got 6 P-States 29, 32, 34, 36, 38, 40 which i obtained using VoodooPState.kext.
View attachment 47082

When DCPI manager shows Current P-State: 29 CPU Multiplier Shows 6x in HWmonitor from Kozlek branch and so on

P-State 29 > CPU multiplier 6x
P-State 32 > CPU multiplier 7x
P-State 34 > CPU multiplier 8x
P-State 36 > CPU multiplier 9x
P-State 38 > CPU multiplier 10x
P-State 40 > CPU multiplier 11x (full load)

according to Wikki this should be reversed.

 

[SJ_UnderWater]

It doesn't look like you read what I wrote, because I distinguished between the DPCI feature currently-named "PStates" (though that could change before release) and the P-States you read "from wikki(IBM) pages", and then also between Core i CPUs and your Core 2.
The P states you're thinking of are P0, P1, etc; the ones given by DPCI are 12,16,29,40, etc -- completely different numbers and letters. Did you notice that the "VID" column given by that Voodoo app corresponds exactly to DPCI's output, though converted from hex to decimal? What would I "reverse"? The list given in the log is sorted in ascending order for readability.
PStates could become more complex in the future, reading offset 14, offset 46 for more information, but right now I want to keep it simple: an easier way of getting MSRDumper's primary output without manually loading a kext, watching the kernel log, then unloading it. I didn't even add the "Current" log entry until I was asked.

 

[tonymacx86]

Great work on this SJ- this is a really helpful tool!

Testing latest, I just got this in console- don't know if this will help:

DPCIManager[6798]: *** WARNING: Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.

 

[SJ_UnderWater]

I don't think I can fix that one, since I don't call that method in any of my code. I suspect it's done automatically somewhere.

 

[Gordo74]

This looks like a really cool tool SJ.

Based on my hardware, what would patching the BIOS do with "auto patch"? I'm just curious. I don't want to do it just for curiosity sake and then brick the board/not be able to boot into OSX.

 

[nobodynose]

This is a great tool - keep up the good work!

I apologize for going slightly off topic, but I have a question about PStates/multipliers. I'm running with a Core i3-2125, and the only multipliers I ever see it running at are 16 and 33 (very rarely I've seen 18). Should there be more steps than this?

 

[SJ_UnderWater]

This looks like a really cool tool SJ.
Based on my hardware, what would patching the BIOS do with "auto patch"? I'm just curious. I don't want to do it just for curiosity sake and then brick the board/not be able to boot into OSX.

On a Gigabyte it would read your current BIOS to a temporary file, then attempt to patch it for power management. This would fail because your BIOS does not need patching, then the procedure would stop. If you had an Asus or similar board requiring patching, the patch would succeed and generate a second temporary file, which would be flashed to the board, after checking that the FD44 information was intact, which it would because it came directly from the board (not a stock ROM).

This is a great tool - keep up the good work!
I apologize for going slightly off topic, but I have a question about PStates/multipliers. I'm running with a Core i3-2125, and the only multipliers I ever see it running at are 16 and 33 (very rarely I've seen 18). Should there be more steps than this?

You should be getting more than two, a sign that a Sandy Bridge SSDT is necessary for "better" power management. One caution at the moment is I will still need to tweak the refresh rate for PStates, possibly to gather more or to reduce the load on the system. You should definitely see more than two states though.

 

[nobodynose]

You should be getting more than two, a sign that a Sandy Bridge SSDT is necessary for "better" power management. One caution at the moment is I will still need to tweak the refresh rate for PStates, possibly to gather more or to reduce the load on the system. You should definitely see more than two states though.

I only see two when I use MSRDumper.kext as well, so it isn't your tool. What's a good resource for learning how to create an SSDT for my lowly i3 (given that they're only included in MultiBeast for the i5's and i7's)?