Jump to content

64bit p-state

hnak

By hnak,
in Intel SpeedStep

 Share
131 posts in this topic

Recommended Posts

userx
userx
Posted
Posted
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... :)

Link to comment
Share on other sites
Brewers
Brewers
Posted
Posted

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 :)

Link to comment
Share on other sites
hnak
hnak
Posted
  • Author
Posted
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. :D

Ooops! It is a sign of memory leaks.

I uploaded a fixed version (1.0.3).

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

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: ) ).

Link to comment
Share on other sites
aka120
aka120
Posted
Posted
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 B)

 

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 :blink:

 

 

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

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

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 -) :D

 

Problem with 1.0.3 :

Bug: Voltage is shown always 0 :unsure: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

Bildschirmfoto_2009_10_21_um_07.09.54.jpg

Bildschirmfoto_2009_10_21_um_07.28.13.jpg

Link to comment
Share on other sites
hnak
hnak
Posted
  • Author
Posted
yes... v1.0.3 uses twice the cpu %.

You check the cpu % with Performance monitor ?

 

It can be caused by the default timer interval difference if you use the default preference values.

If you use the same timer interval, the difference may be due to doc icon update.

The only other difference is releasing memory in 1.0.3 to fix memory leak bug.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

Hint:

You can set the interval of refreshing / sec of the controller app in his Pref.

Simple set higher value from 400 mS to 1000mS. 1 refresh / sec is enough to show changes.

For my knowledge this didnt change the speed of trotthling, its only cosmetic for showing faster/slower (less cpu %) the results.

 

I found an key in the .kext .plist which may do also change cpu % usage of the trottling background .kext itself.

There is an default of 100 . I believe that stands for 100mS interval checking cpu load and compute to throttle or not throtthle. 10 times / sec (100 mS) maybe very fast (and noticable cpu usage of the kext itself !) . I switched to 200 (ms), means 5 times / Sec . Even 300 may be fast enough (3 times / Sec) to check+do throttling. The higher that value the slower the reaction of thotthling if cpu load changed.

But 200 - 300 mS may fast enough to avoid noticable system slowness if cpu load rised and throttling up was a bit to slow.

Link to comment
Share on other sites
hnak
hnak
Posted
  • Author
Posted
In your new ver.

 

I have no sleep problem.

It's strange.

As my systems have never succeeded in sleep, I have no way to investigate it.

 

How about add menu bar funtion?

 

I think it will better than dock icon....

As the menu bar is regarded as Apple-reserved, they discourage using it as far as I know.

If you ( or someone else ) are interested in building a menubar app, http://www.makeuseof.com/tag/11-tiny-and-u...ations-for-mac/ might be a good reference.

Link to comment
Share on other sites
haraldschmidt
haraldschmidt
Posted
Posted

Hey hnak,

 

thanks sooo much ! Great work ! I was using voodoopower and stayed in 32 bit mode due to powermanagement and leaking driver support for my 3g modem (usb stick)...

 

But now completly in 64 bit mode with fast system reaction and even cooler temps...

 

Everything runs sooo cool around mid 30 degree temps...

 

QUESTION: can I rely on the temps in the control app? What TjMax Temp is used? I'm running a T8300 should be 105 or 100 degrees I think...

 

I really love the undervolting part, can't wait to see how my battery lifetime will develop...

 

 

 

Thanks a lot,

 

Harry

 

PS: for menubar integration maybe superhai is a help, his control.app had a hide to bar functionality

Link to comment
Share on other sites
hnak
hnak
Posted
  • Author
Posted
QUESTION: can I rely on the temps in the control app? What TjMax Temp is used? I'm running a T8300 should be 105 or 100 degrees I think...

 

PS: for menubar integration maybe superhai is a help, his control.app had a hide to bar functionality

About TjMax, please check the code ( intel.cpp ). I just modified VoodooPower's code to return absolute temperature instead of a value relative to TjMax. TjMax extraction code is untouched.

 

For menubar, I am just lazy enough to be satisfied with doc icon or using spaces to make it disappear for now.

I will think about UI after Core i5.

Link to comment
Share on other sites
  • 2 weeks later...
bcc9
bcc9
Posted
Posted

I've found that on my laptop (dell studio xps 1340) the super-lfm pstates cause the system to lock-up hard as soon as voodoopstate or voodoopower is run. I reported this to superhai with a fix a while back but he didn't integrate any support into voodoopower. Linux&windows don't have a problem with p-states on this laptop, but linux and apparently windows just pick up the min-max levels from the ACPI dynamic pstate tables (_PSS in the dynamic SSDT tables), which for this laptop, don't include the super-lfm states.

 

So here is a patch for VoodooPState that disables the super-lfm p-states if broken_lfm is set. I think it would be nice to make this a config option in Info.plist.

 

PS: Thanks for picking up where voodoopower left off; I think voodoopstate is really handy.

 

Edit: Better diffs included in my next post, 2 posts below.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

Hi, i see that teh 64 Bit version does also shows the 0.5 * Pstates (screenshoot) in SL.

With same dsdt (here my Pstates) in Leo + Leo Version of Pstates that also x.5 Steps are not shown , means not 7 Pstates (dsdt) only 4 with x.0 stepsshown.

 

Can the dev look into the codes if Leo Version code has some differences that it cant show that x.5 Pstates.

Also would be nice to know its only an cosmetic problem (not showing that x.5 steps) but using them, or also not using them if not shown.

 

mitchs Pstates with also x.5 * FSB Steps / SL.

Bildschirmfoto_2009_11_05_um_12.32.57.jpg

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

Here's a new version of my super-LFM patch. It also includes a fix for a rounding error in intel_probe(), where cumulative rounding errors in vidstep causes the p-states to use higher frequencies than necessary.

 

The rounding problem is independent of the LFM problem, and also exists in the VoodooPower version of this code.

 

With this change, my 6x p-state runs with .0125v less :)

 

 
*** intel.orig.cpp	2009-10-20 00:03:32.000000000 -0700
--- intel.cpp	2009-11-06 13:49:04.145023634 -0800
***************
*** 92,97 ****
--- 92,99 ----

 bool intel_probe(VoodooPState* vp)
 {
+	 bool broken_lfm = true;
+ 
  // assign callbacks
  vp->VoodooReadProc = IntelReadProc;
  vp->VoodooWriteProc = IntelWriteProc;
***************
*** 304,317 ****
  if (vp->PStateControl) {
	  vp->PStateCount = Maximum.cid - Minimum.cid + 1;
	  if (vp->PStateCount > PStateCountMax) vp->PStateCount = PStateCountMax;
-		 UInt8 vidstep;
	  UInt8 i = 0, invalid = 0;
!		 vidstep = ((Maximum.vid << 2) - (Minimum.vid << 2)) / (vp->PStateCount - 1);
	  for (UInt8 u = 0; u < vp->PStateCount; u++) {
		  i = u - invalid;
		  vp->PState[i].cid = Maximum.cid - u;
		  vp->PState[i].fid = (vp->PState[i].cid >> 1);
		  if (vp->PState[i].fid < 0x6) {
			  if (vp->Intel_DynamicFSB) vp->PState[i].fid = (vp->PState[i].fid << 1) | 0x80;
		  } else {
			  if (vp->NonIntegerBusRatio) vp->PState[i].fid = vp->PState[i].fid | (0x40 * (vp->PState[i].cid & 0x1));
--- 306,336 ----
  if (vp->PStateControl) {
	  vp->PStateCount = Maximum.cid - Minimum.cid + 1;
	  if (vp->PStateCount > PStateCountMax) vp->PStateCount = PStateCountMax;
	  UInt8 i = 0, invalid = 0;
!		 UInt8 u, cid;
! 
!		 if (broken_lfm) {
!			 /* Subtract off super lfm P-state entries */
!			 for (u = 0; u < vp->PStateCount; u++) {
!				 cid = Maximum.cid - u;
!				 if ((cid >>1) < 0x6) {
!					 break;
!				 }
!			 }
!			 if (u) {
!				 Minimum.cid = cid+1;
!				 vp->PStateCount = Maximum.cid - Minimum.cid + 1;
!			 }
!		 }
	  for (UInt8 u = 0; u < vp->PStateCount; u++) {
		  i = u - invalid;
		  vp->PState[i].cid = Maximum.cid - u;
		  vp->PState[i].fid = (vp->PState[i].cid >> 1);
		  if (vp->PState[i].fid < 0x6) {
+				 if (broken_lfm) {
+					 invalid++;
+					 continue;
+				 }
			  if (vp->Intel_DynamicFSB) vp->PState[i].fid = (vp->PState[i].fid << 1) | 0x80;
		  } else {
			  if (vp->NonIntegerBusRatio) vp->PState[i].fid = vp->PState[i].fid | (0x40 * (vp->PState[i].cid & 0x1));
***************
*** 321,333 ****
				  invalid++;
			  }
		  }
-			 vp->PState[i].vid = ((Maximum.vid << 2) - (vidstep * u)) >> 2;
	  }
	  vp->PStateCount -= invalid;
	  if (!vp->PStateCount) {
		  ErrorLog("Insane P-State values");
		  return false;
	  }
  } else {
	  return false;
  }
--- 340,357 ----
				  invalid++;
			  }
		  }
	  }
	  vp->PStateCount -= invalid;
	  if (!vp->PStateCount) {
		  ErrorLog("Insane P-State values");
		  return false;
	  }
+		 /* Avoid cumulative roundoff errors in vidstep by computing
+			delta directly */
+		 for (i = 0; i < vp->PStateCount; i++) {
+			 vp->PState[i].vid = Maximum.vid -
+				 ((Maximum.vid - Minimum.vid)*i / (vp->PStateCount - 1));
+		 }
  } else {
	  return false;
  }

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted
Here's a new version of my super-LFM patch. It also includes a fix for a rounding error in intel_probe(), where cumulative rounding errors in vidstep causes the p-states to use higher frequencies than necessary.

 

The rounding problem is independent of the LFM problem, and also exists in the VoodooPower version of this code.

 

With this change, my 6x p-state runs with .0125v less :)

 

 *** intel.cpp	2009-10-20 00:03:32.000000000 -0700
 --- intel.cpp.new2	2009-11-05 15:38:00.913023711 -0800
 ***************
 *** 92,97 ****
 --- 92,99 ----
 
   bool intel_probe(VoodooPState* vp)
   {
 +	 bool broken_lfm = true;
 +
 
Can you upload scuh an modded ready to run build somewhere. 
Doe this also is for Leo version of VoodooPstate ?
Thanks
Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
Can you upload scuh an modded ready to run build somewhere.

Doe this also is for Leo version of VoodooPstate ?

I've posted a build of just my modified voodoopstate.kext, based upon hnak's 1.0.3 version, in this thread, specifically here's the kext

Update: New version, v4, here

 

I built with hnak's default settings, which means it's a 10.6 only bundle. 10.5.x kexts would have to be built separately.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...