Jump to content

Experimental Intel SpeedStep kext


mercurysquad
 Share

291 posts in this topic

Recommended Posts

Sometimes the throttlin happens quiet often, and the strain all the IOLog outputs put on the system causes stutter.

 

You can adjust the trottling in the Speedstep App (the newer one, enhanced) by setting the Thresshod for cloccking down and clocking up.

So it stays a bit longer at higher MHZ and also longer at lower MHZ = less switching.

 

The preferences is until now NOT saved, so we must wait for next rev of speedstep app.

 

Dont set Cpu Load Interval to much to left (often checking CPU %) Speedstap then takes much CPU time, but may react to CPU% changes faster.

Bild_107.jpg

Link to comment
Share on other sites

This is a great job!

I tested and it works pretty good. No suttering whatsoever

I've using coolbook for a couple of months and well that was the only solution if you wanted to update the kernel (Im running 9.4.0 vanilla). With the old speedstep package (acpithrottler kext) I used to get lower temperatures than with coolbook. One thing is that both, coolbook and the old acpithrottler.kext, could make the cpu going to 800 mhz. Your new kext only give me 3 steps: 1200, 1600 and 2000...

I tried to add the 800 mhz on the plist but it doesnt work like that either.

I have a C2D T7250 (stepping:13 model:15 family:6)

I hope you will add n/2 bus ratio soon

Thanx for your exellent job!

 

BTW, Im using the new speedstep_beta app...

Link to comment
Share on other sites

Intel Core Duo T2500 (family 6, model 14, stepping 8)<---according to "sysctl machdep.cpu && uname -a".

 

I am using 9.4 vanilla kernel.

 

I have set up my own P-state table based on windows values. Without setting up the P-state table no states are detected. In windows the voltage does go as low as 950mV so i dont think the processor is limiting it.

 

sudo dmesg | grep IntelEnhancedSpeedStep

 

sysctl machdep.cpu && uname -a

 

sysctl -a | grep throttle

 

Thanks again

 

Ok, it is exactly what I thought it would be. It is as follows:

 

The kext is correct: your CPU is running at 1004 mV, not 950 as reported in Windows. The voltage ID (VID) is 19 for the lowest p-state (998MHz), as seen from your logs.

 

Your CPU uses 700 mV offset with 16 mV steps per VID. So using the formula 700+VID*16 = 700+19*16 = 1004 mV. Coolbook as well as the Windows app you are using is assuming (incorrectly) that the offset is 712.5 mV with 12.5 mV, giving you 712.5+12.5*19 = 950 mV.

 

I hope that clears the confusion. As far as I know Core Duo's (6/14) *don't* use 12.5mV steps. Only 45nm penryn based CPUs use that.

 

In either case, the lowest VID is 19 in Windows, Coolbook and the kext. It's just a matter of conversion of the VID into millivolts which let me repeat, the kext is doing correctly and Coolbook/Windows app are doing incorrectly :(

 

1004 is reported by terminal, but Coolbookcontroler report 950mv as it's specified in plist...

I've tried with my old speedstep kernel (92) : no change, still stuttering with app Gui and terminal...

 

Once again, Coolbook incorrectly assumes the CPU uses 712.5 mV offset with 12.5 mV / VID step. This is incorrect and causes a lower voltage to be displayed for most 90nm or 65nm processors. The kext is correct in 95% of the cases while it's the other way round for Coolbook.

 

As for stuttering, it could be because of the verbose log output (it pauses for a while after each log message). I'll make the log output optional for 1.3, default turned off. Also some more changes are expected for better fsb ratio support, which should also help with the stuttering. Also use an EFI bootloader if you're not already using it (actually this kext requires EFI).

Link to comment
Share on other sites

Thanks a lot for this. It is working well for me probably because my system is similar to yours:-) (Dell Precision M60 with 1.7GHz Pentium M running Kalyway 10.5.2 with your 9.2 rtcfix SSE2 kernel). The command line stuff works fine but neither tuxx application works (they just start up & die).

 

It would be really great if you can implement this with sub-1GHz frequencies as under Windows my system throttles down to just 600MHz & runs very cool & quiet. In OSX even with your excellent kext it of course only throttles down to 1GHz & thus runs hotter & the fans which are controlled by the BIOS kick in more.

 

Using the Notebook Hardware Control application under Windows I get these pstates

 

600MHz 0.956V

800MHz 1.004V

1000Mhz 1.116V

1200MHz 1.228V

1400MHz 1.308V

1700MHz 1.484V

 

With IntelEnhancedSpeedStep.kext I get 

 

kern.cputhrottle_freqs: 1000 1200 1400 1600 1700 1700

Link to comment
Share on other sites

You can adjust the trottling in the Speedstep App (the newer one, enhanced) by setting the Thresshod for cloccking down and clocking up.

So it stays a bit longer at higher MHZ and also longer at lower MHZ = less switching.

 

The preferences is until now NOT saved, so we must wait for next rev of speedstep app.

 

Dont set Cpu Load Interval to much to left (often checking CPU %) Speedstap then takes much CPU time, but may react to CPU% changes faster.

 

While that may help, the primary issue is the large amount of debugging information being printed to dmesg. When this kext leaves beta, I am hoping that 99% of the output will be eliminated thus helping to eliminate the slight stutter that occurs upon switching.

Link to comment
Share on other sites

Still having a few issues here that i cant seem to figure out.

 

1. the kext seems to load when i do a verbose startup, but once i'm into the osx gui it isn't loaded anymore. The commands to see frequency etc do not work, and I have to load the kext manually, and then it will be loaded. permissions are set correctly.

EDIT: After some fiddling, it now loads at startup.

 

2. Upon loading of the kext, if i do a "sysctl -a | grep throttle", it lists the frequency as 1996, and the voltage as 1404. This would seem correct based on your new calculations, but, according to wikipedia, my processor should only go from 0.762/1.3 V, not up to 1.404V.

 

3. If i try to change the frequency while the voltage is in it's initial state (1404), i get a kernel panic. If i set the voltage using curvolt to a lower number, then I can change frequencies as usual without KP, until my next reboot.

EDIT: any changes in voltage/frequency result in kernel panic/frozen desktop :S

 

Thanks once again for this amazing kext.

Link to comment
Share on other sites

New version 1.3 is up. Still needs testing as major new feature half-bus ratio is added (N/2 fsb ratio).

See first page for download link and more info.

 

This should now allow most kernels/processors to go below 1Ghz, including real macs.

 

Please note that the kext's auto-detection of Pstate table is only to be used as a quick-fix fallback if you don't want to create your own pstate table. The reason being that half the time acpi reports incorrect values. So if possible, make your own pstate table. You have to fill in the values in Info.plist and then change the name from PStateTableDisabled to PStateTable.

Link to comment
Share on other sites

While that may help, the primary issue is the large amount of debugging information being printed to dmesg. When this kext leaves beta, I am hoping that 99% of the output will be eliminated thus helping to eliminate the slight stutter that occurs upon switching.

 

Yeah.

 

But perhaps it is possible to get same beta but with less dmesg output (an "quite 1.22 beta") ?

Link to comment
Share on other sites

Yeah.

 

But perhaps it is possible to get same beta but with less dmesg output (an "quite 1.22 beta") ?

 

New one 1.3.1 disables debug messages by default. You can enable it by setting DebugMessages key to true in the Info.plist.

 

Thanks a lot for this. It is working well for me probably because my system is similar to yours:-) (Dell Precision M60 with 1.7GHz Pentium M running Kalyway 10.5.2 with your 9.2 rtcfix SSE2 kernel)

It would be really great if you can implement this with sub-1GHz frequencies as under Windows my system throttles down to just 600MHz & runs very cool & quiet.

1.3.1 has support for <1Ghz frequencies, however the 9.2 rtcfix kernel will panic when going below 1ghz. Wait for my 9.4 kernel, it supports <1Ghz with sleep+speedstep+rtcfix.

Link to comment
Share on other sites

thanks! that seems to have fixed it.

 

small bug, seems that when changing frequencies it does not always report the change (ie still says kern.cputhrottle_curfreq: 1830 -> 1830), though checking the frequency after issuing the command confirms that it is in fact changing the frequency properly.

 

seems to have fixed the kernel panics so far.

Link to comment
Share on other sites

Indeed, setting the values returns no change, thus the GUI tools don't display any changes. But if frequencies are really changed, then mercurysquad did really get rid of the stuttering! No sound interruptions here so far when manually changing from the CLI. It's getting better and better!

Link to comment
Share on other sites

thanks! that seems to have fixed it.

 

small bug, seems that when changing frequencies it does not always report the change (ie still says kern.cputhrottle_curfreq: 1830 -> 1830), though checking the frequency after issuing the command confirms that it is in fact changing the frequency properly.

 

seems to have fixed the kernel panics so far.

I am still experimenting with the delay to allow for freq changing. Apparently sysctl is a bit impatient. Right now it waits until X usec (typically ~10) as reported by ACPI, but I think bumping it up to 120 usec or similar should be enough. Maybe for 1.3.2.

 

Just know that the freq does change even if sysctl doesnt display it immediately. SpeedStep gui seems to work ok and does display the change (since it checks once or twice a second, enough for the cpu speed to have changed).

Link to comment
Share on other sites

i know this isnt the thread to be asking, but where can we find info about updates to speedstep.app. it randomly shuts off on my computer without notice.

Use the old one (not improved beta). Thats a bit more stable if it starts up at all.

The guy 'tuxx' is out on vacation for the next week.

Link to comment
Share on other sites

Just reporting back :)

 

CPU/Mobo: Core 2 Duo E6750 2.66 GHz, OC'd to 2.8 GHz/Abit Fatal1ty FP-IN9 (nForce 650 SLi Chipset)

Kernel: Darwin Kernel Version 9.4.0: Sat 2 Aug 2008 18:35:36 BST; iGuru:xnu-1228.5.20-nForce/BUILD/obj/RELEASE_I386 i386

(Custom 10.5.4 nForce Kernel, no speedstep support integrated in kernel)

 

Due to the nForce ACPI being a pain in the ass as always, the kext obviously didn't detect the default Power States, I played about with PStates manually, and finally narrowed the viable frequencies down to: 2000, 2500 and 2800 MHz. No matter what other PStates I added, it would not go below 2000 MHz under Mac.

 

Loaded v1.3.1, started "tuxx_SpeedStep_improved_beta.tar", left on auto. It automatically stepped up/down as required, there was no audio stuttering, obvious slowdowns, etc.

 

Debug/Further Info: http://paste2.org/p/58137

 

Cheers for the great kext mate!

Link to comment
Share on other sites

Tested 1.3.1, It wouldnt go below 1200. I used to get 800 mhz with the old ACPIthrottle.kext and with coolbook.

C2D T7250 (stepping:13 model:15 family:6). I get only 1200, 1600 and 2000 mhz.

Is there a way to force it?

Link to comment
Share on other sites

Just would like to report success on Q6600 b3 stepping overclocked to 3.0 GHz (9x333, VCore 1.2625V)

 

Info.plist

<key>PStateTable</key>

<array>

<array>

<integer>2997</integer>

<integer>1262</integer>

</array>

<array>

<integer>2331</integer>

<integer>1262</integer>

</array>

<array>

<integer>1665</integer>

<integer>1262</integer>

</array>

<array>

<integer>999</integer>

<integer>1262</integer>

</array>

 

sysctl -a | grep throttle

kern.exec: unknown type returned

kern.cputhrottle_curfreq: 1665

kern.cputhrottle_curvolt: 1260

kern.cputhrottle_freqs: 999 1665 2331 2997

kern.cputhrottle_factoryvolts: 1260 1260 1260 1260

kern.cputhrottle_ctl: 1571

 

No stuttering so far...

999 MHz is not working, but will just keep the PTable for now.

Also need to optimize the voltages in the PTable... any suggestion?

Link to comment
Share on other sites

ok, i am now noticing a few issues after having some time to test in more depth:

 

using your kernel and your speedstep.kext music can play at full speed but if the processor speed is adjusted it skips after a few seconds and sometimes it will recover...other times it will not.

 

using your kernel and both speedstep.kext and acpicputhrottle.kext things go more smoothly but music begins to get garbled after a few seconds and eventually becomes completely unusable

 

using your kernel and acpicputhrottle plays music almost perfectly with almost no skipping as long as itunes is the frontmost window...if other processes are happening it seems to get garbled. this is the most usable situation and what i am using. does this mean acpicputhrottle is doing something speedstep.kext isnt?

Link to comment
Share on other sites

999 MHz is not working, but will just keep the PTable for now.

 

Try changing it to 1000 instead.

 

using your kernel and both speedstep.kext and acpicputhrottle.kext

does this mean acpicputhrottle is doing something speedstep.kext isnt?

 

Do not use both kexts simultaneously!

 

ACPICPUThrottle is doing nothing extra that speedstep.kext isn't doing. Infact the kext send carefully calculated clock recalibration signals to the kernel while acpicputhrottle sends only an approx value. If you still experience stuttering with 9.2rtcfix kernel, just wait for 9.4 kernel. I am currently using/testing this combination and it works flawlessly. Which CPU do you have btw?

Link to comment
Share on other sites

inspiron 6000 with pentium M 1.86...i believe

 

i put it all in my sig. seems like i will be doing more and more on this site now so it might be good to do.

 

also, after time it seems like speedstep.kext plays music better in the background but, like i said, acpicputhrottle does it better initially...this stuff is crazy, it seems to change all the time and i am having a hard time figuring out exactly what is going on with all of it.at least things are usable now.

Link to comment
Share on other sites

Well try this 9.4 kernel http://www.sendspace.com/file/q1j9e7 -- this is VERY beta and very experimental, but I'm just giving it to you to check whether the kernel is the problem or the kext. The combination of this kernel and the kext should solve all your stuttering issues.

 

Also an lurkers here who will d/l this kernel, if you have 64bit cpu, boot with -legacy

Link to comment
Share on other sites

just wondering, will you be releasing the kernel source as well so others could compile kernels as apple updates them?

 

i've shaved 10degrees celsius off my average cpu temp using speedstep! none of the guis work fully yet so i just set it down to 998mhz while doing webbrowsing etc.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...