128 replies to this topic

[Brewers]

hnak, on Oct 12 2009, 09:10 AM, said:

So the problem is not in kext but application. It should be easy if my system could sleep...

My system can sleep, and as you quoted, we use the same MB... I will post a list of my kexts and further configuration when I get home this afternoon, so that we can set up your system for sleep

[mitch_de]

hnak, on Oct 2 2009, 12:02 AM, said:

You hear "DONG" if you set pstate-min (highest) > p-state max (lowest). Did you change only pstate-min from default ?

Sorry, i dl lastest and also dong, dong, dong in the preferences.
I cant change anything, also the threshoots not.
Always on "dong". Only when i press Defaults no dong and the default is shown.
If i change any of the prefs and press Apply or Save i hear a dong.

So how i can set my PStateLimit to 1 (not going to PSate 0) ?

Can you add those prefs not also in the .kext ?
This may be needed, because i cant kextload the .kext and must first setup the Limit to 1 in the Psatechanger.
Or does all dongs come because at this moment no .kext is loaded ? As i said i cant load the kext without be sure that it didnt switch in Pstate 0 (highest Mhz).

[hnak]

mitch_de, on Oct 12 2009, 11:26 AM, said:

Sorry, i dl lastest and also dong, dong, dong in the preferences.
I cant change anything, also the threshoots not.
Always on "dong". Only when i press Defaults no dong and the default is shown.
If i change any of the prefs and press Apply or Save i hear a dong.

So how i can set my PStateLimit to 1 (not going to PSate 0) ?

Can you add those prefs not also in the .kext ?
This may be needed, because i cant kextload the .kext and must first setup the Limit to 1 in the Psatechanger.
Or does all dongs come because at this moment no .kext is loaded ? As i said i cant load the kext without be sure that it didnt switch in Pstate 0 (highest Mhz).

You cannot change prefs unless you load the kext. It checks if p-state <= max.
It's safe to load the kext as it switches p-state to max available (lowest clock) at startup.

[mitch_de]

hnak, on Oct 12 2009, 02:56 PM, said:

You cannot change prefs unless you load the kext. It checks if p-state <= max.
It's safe to load the kext as it switches p-state to max available (lowest clock) at startup.

Excat  !
I did load now the .kext and set the pState Limit later. So it does work now. I thought it would be better to set the klimit before using the .kext.
How does the .kext knows at next usage about that setting ?
Its because i didnt know where that limit is saved. For example if i kextload it at next boottime (without starting the PstateChanger again) in an high cpu usage situation and it will not now that limit i will get KP for sure.

Thanks !!

[hnak]

mitch_de, on Oct 12 2009, 05:18 PM, said:

Excat  !
I did load now the .kext and set the pState Limit later. So it does work now. I thought it would be better to set the klimit before using the .kext.
How does the .kext knows at next usage about that setting ?
Its because i didnt know where that limit is saved. For example if i kextload it at next boottime (without starting the PstateChanger again) in an high cpu usage situation and it will not now that limit i will get KP for sure.

Thanks !!

Good! I make the mechanism a little bit clearer.
Kext does not know anything about the setting. It just sets p-state to the lowest clock at startup and waits for incoming requests of p-state switch.
Preference is saved/loaded by PStateChanger application. So, p-state never rises unless the application runs.

[mitch_de]

hnak, on Oct 13 2009, 12:41 AM, said:

Good! I make the mechanism a little bit clearer.
Kext does not know anything about the setting. It just sets p-state to the lowest clock at startup and waits for incoming requests of p-state switch.
Preference is saved/loaded by PStateChanger application. So, p-state never rises unless the application runs.

That could be problematic in my case (never should switch to Psate 0)- if i would kextload it in an high cpu load situation it will KP my system getting to Pstate 0 before i can run the PStateChanger to Limit Pstate to 1.
would be nice to add, like you have done for Voltage settings and voodoopower has for all settings, to include the Pstate Limits also in the .plist of the .kext.

[hnak]

mitch_de, on Oct 13 2009, 06:32 AM, said:

That could be problematic in my case (never should switch to Psate 0)- if i would kextload it in an high cpu load situation it will KP my system getting to Pstate 0 before i can run the PStateChanger to Limit Pstate to 1.
would be nice to add, like you have done for Voltage settings and voodoopower has for all settings, to include the Pstate Limits also in the .plist of the .kext.

PState.kext  NEVER raises p-state from the lowest level unless PStateChanger is launched ( no matter how much cpu load exists ). So, if you kextload in high cpu load situation, it just slows down CPU, or does nothing if already in the lowest state.
Only PStateChanger changes p-state.
Just launch PStateChanger when your cpu is not busy, then apply & save prefs. It will not take 10 seconds.

If you think 10 seconds are too long, just modify the code to set min p-state to 1 and build your customized app.
Change defaultPref() of preference.c as:

void defaultPref(PSTATECHANGER_PREF* pPref, int pstateCount){
	...
	pPref->pstate_min = 1; // 0;
	...
}

In which p-state does your system boot when there is no p-state controlling kext loaded ?

[mitch_de]

THANKS !! No need for .plist changes if the .kext leave CPU on slowest MHZ (Pstate) until the control app is started.
highest
Without any OS X .kext for pstates ? I think it will stay always in the fastest MHZ available.
Because the bios limits the multi (9*333 , default: 10*266) i have Psates für multi 6+7+8+9 (not 10).
All that 4 (not the 10*) are as psates listed in the dsdt.
Whats funny is that, if i use that iMark (was iCPU) tool (also app + .kext set) it switches never to the problematic pstate 0 (10* ) , their i get pstate 4 (6*) up to pstate 1 (9*).


Have you ever tried to limit (set down one for an test) the multi in your  bios ? It should not damage you CPU if you switch down one multilevel.
The .kext seems to not see / acept that and tries to set highest multi (in my case 10 *) even if not available (limited by bios).

[Brewers]

hnak,

can you modify the app so that it doesn't show the CPU graph in the dock, or best, doesn't show up at all? The graph is quite ugly, and I do not like moving things in my dock. I searched for a way to hide apps there, but Google wasn't particularly helpful.

Maybe you can make this behaviour optional, for those that like a CPU graph in their dock

[hnak]

mitch_de, on Oct 13 2009, 05:40 PM, said:

Have you ever tried to limit (set down one for an test) the multi in your  bios ? It should not damage you CPU if you switch down one multilevel.
The .kext seems to not see / acept that and tries to set highest multi (in my case 10 *) even if not available (limited by bios).

No, I haven't.
I actually did not change the logic of kext and it is exactly the same as VoodooPower, which does not extract information from BIOS.

Brewers, on Oct 13 2009, 06:29 PM, said:

hnak,

can you modify the app so that it doesn't show the CPU graph in the dock, or best, doesn't show up at all? The graph is quite ugly, and I do not like moving things in my dock. I searched for a way to hide apps there, but Google wasn't particularly helpful.

Maybe you can make this behaviour optional, for those that like a CPU graph in their dock

For now, you can use 1.0.1 to avoid Doc icon animation.

[userx]

Brewers, on Oct 13 2009, 10:29 AM, said:

hnak,

can you modify the app so that it doesn't show the CPU graph in the dock, or best, doesn't show up at all? The graph is quite ugly, and I do not like moving things in my dock. I searched for a way to hide apps there, but Google wasn't particularly helpful.

Maybe you can make this behaviour optional, for those that like a CPU graph in their dock

You can use Dock Dodger to get rid of the dock icon all together. Set PStateChanger to "hide" in Login Items. A reboot may be required to get rid of the PStateChanger window from popping up after you use Dock Dodger.

http://foggynoggin.com/dockdodger

Check Activety Monitor to make sure it's running.

Hope that helps...  

[Brewers]

Thanks, I already found a similar application, called Dockless

On another note... I get a 'hanging' mouse cursor whenever the Pstate changes. The cursor stays in its place and jumps to the actual position where it's supposed to be shortly afterwards (after the timer interval? Already set it to 250ms, but it doesn't seem to help).

Also, the memory usage is quite hefty, uses 300Mb after running nonstop for 3 days. Doesn't really concern me, since I have 8GB of RAM, but others may feel different.

Apart from that, no problems so far, no crashes, etc. Quite a nice tool

[hnak]

Brewers, on Oct 19 2009, 04:26 PM, said:

Also, the memory usage is quite hefty, uses 300Mb after running nonstop for 3 days. Doesn't really concern me, since I have 8GB of RAM, but others may feel different.

Ooops! It is a sign of memory leaks.
I uploaded a fixed version (1.0.3).

[markswell]

Quote

Whats funny is that, if i use that iMark (was iCPU) tool (also app + .kext set)

metchde my tool is not based on voodoomonitor/cpu-i or generic/voodoopower, it do another way.

[mitch_de]

Thanks imark  for clearing difference way of throttling for iMark.
Latest iMark & Ringpower.kext does work in 10.5(with 10.5 kext version) and 10.6 very well with my OC sytem : BIOS FSB higher but one step in fsb multiplier less = no KPs as with voodoopoer based tools  without manual limit to PState 1: ) ).

[userx]

I find that v1.0.1 uses half the CPU of v1.0.3. Does v1.0.1 also have memory issues?

[mitch_de]

userx, on Oct 20 2009, 11:44 PM, said:

I find that v1.0.1 uses half the CPU of v1.0.3. Does v1.0.1 also have memory issues?

?? Whatt do you mean with "half" . Half of CPU % using the control app ?

[aka120]

Brewers, on Oct 13 2009, 12:29 PM, said:

hnak,

can you modify the app so that it doesn't show the CPU graph in the dock, or best, doesn't show up at all? The graph is quite ugly, and I do not like moving things in my dock. I searched for a way to hide apps there, but Google wasn't particularly helpful.

Maybe you can make this behaviour optional, for those that like a CPU graph in their dock

I know its a bit late, but you can hide the dock icon without any third party apps...
just edit the PStateChanger.app's info.plist, to include this key/string...

[KEY]NSUIElement[/KEY]
   [STRING]1[/STRING]

And this will hide the icon from the dock permanently


On a side note, I wouldn't call it an "ugly" graph, that's a bit harsh...

[mitch_de]

NEWS + Pstates HINT:
I found out that latest (1.0.3) .kext has an key to enable UseACPI.
It switches to an other way to get the available Pstates (if set NO=default) the .kext uses an build in routine to compute all possible Psates from cpu type and fsb.
With UseACPI set YES it takes the bios/dsdt psates.
Advantage of NO(default) is, that those voodoopower based .kext can compute pstates even bios or dsdt havent pstates to give. Other powermanager may fail if ACPI (bios or dsdt) didnt have pstates.
Problem of NO (default) is, that if someone set multi in bios up or down the voodoopower gets wrong with the availbale pstates (KP or not full speed).
Now i must not limit to Psate = 1 (with control app prefs) anymore to avoud KP in an OC System (OC by FSB+, Multi -)

Problem with 1.0.3 :
Bug: Voltage is shown always 0 Was not with before versions, there where correct Volts shown (no UseACPI key).

Pics left shows Pstates 0 - 3 (max. 2999 MHz) =correct if with UseACPI YES ,
with UseACPI NO(default) Pstates 0 -4, Pstate 0=3333 Mhz = not available / not in dsdt (ACPI) = much to high for my OC 2666 MHz CPU
right shows Volts always 0

Attached Files

•  Bildschirmfoto_2009_10_21_um_07.09.54.jpg   33.26K   29 downloads
•  Bildschirmfoto_2009_10_21_um_07.28.13.jpg   33.44K   19 downloads

[userx]

mitch_de, on Oct 20 2009, 04:02 PM, said:

?? Whatt do you mean with "half" . Half of CPU % using the control app ?

yes... v1.0.3 uses twice the cpu %.