New tool for undervolt/overclock AMD K8L and K10 processors

[blackshard]

Asus M2NPV-MX



With the code change the values are identical to K10stat.


This is true.

I tested non-modifed tpc in OpenSuSE and it worked. There is something in my Gentoo kernel with rejects undervolting.

Thank you for your help and the nice app.

And thank you too for the patience! Nice to know that gentoo kernel rejects cpu MSR modifications.

[blackshard]

Hi blackshard, thanks a lot for the update. I had exactly the same problem (extremely low voltage reported on my AM2 motherboard), and this fixed it. ./TurionPowerControl -l now says

[...cut...]

There is only one thing which is not correctly reported - the frequency. I'm overclocking the processor in the BIOS from 15 x 200 = 3000 to 17.5 x 212 = 3710 Mhz. Memtest86+, dmesg, x86info correctly show "3710 mhz processor", but as you can see Tpc (as well as k10ctl) shows 3500 mhz (that is, 17.5 x 200, as if I hadn't touched the FSB). Simple benchmarks show that the CPU is actually running at 3710 Mhz. Maybe the BIOS is not updating the P-States information correctly? Thanks

Hi kbios, thanks for the reply. It's important to know that it was not an isolated case.

Anyway about wrong frequency, it happens because my program (as the AMD datasheets) always consider a fixed bus frequency of 200 Mhz.

Unfortunately there's no easy way to directly detect the bus frequency because I would need to access the motherboard clock generator chip and this is a difficult task mostly because chip specifications are not public. I think I can address this little issue with sufficient precision using some simple math.

Obtaining the full processor frequency instead is easily done using the Time Stamp Counter (TSC) processor register: that's a register that is increased by one on every clock cycle. That's why dmesg, memtest86+ and other tools report the correct frequency.

[kbios]

Hi kbios, thanks for the reply. It's important to know that it was not an isolated case.

Anyway about wrong frequency, it happens because my program (as the AMD datasheets) always consider a fixed bus frequency of 200 Mhz.

Unfortunately there's no easy way to directly detect the bus frequency because I would need to access the motherboard clock generator chip and this is a difficult task mostly because chip specifications are not public. I think I can address this little issue with sufficient precision using some simple math.

Obtaining the full processor frequency instead is easily done using the Time Stamp Counter (TSC) processor register: that's a register that is increased by one on every clock cycle. That's why dmesg, memtest86+ and other tools report the correct frequency.

Ah, I see. I have a couple of suggestions: the most obvious is to divide the full frequency by the multiplier to get the actual bus frequency; another possibility would be to query the smbios which reports the bus frequency as "external clock".

[blackshard]

Ah, I see. I have a couple of suggestions: the most obvious is to divide the full frequency by the multiplier to get the actual bus frequency; another possibility would be to query the smbios which reports the bus frequency as "external clock".

Yup! The first suggestion is the most intuitive and probably the most exploitable.
The smbus is probably the most precise (obviously!) but it could be a bit difficult to port on windows.

[blackshard]

I made some more investigations on the datasheet and probably I found the mistake I did (and the author of k10ctl did too). Practically the processor takes care of itself about VID encodings.
I guess that all the people with AM2 motherboard and AM2+/AM3 processors should have wrong voltage readings :/

[kbios]

Hi blackshard, I just tested the wonderful pstate unlocking function. I enabled the 5th pstate and set it to 1.0V and 400 Mhz, and it seem to work just fine.However, I have a couple of questions:
1) In the docs you wrote that it is needed to disable the system frequency scaler. But are powernow / acpi pstate kernel drivers still needed or not? Because I'm running a kernel tuned for my hardware and I would be happy to drop some more code.
2) I guess the 5th pstate needs to be reenabled after every reboot. What about suspend/resume? Does the scaler automatically restore settings? Does it need to be restarted?
Thanks again

[kbios]

Hi blackshard, I just tested the wonderful pstate unlocking function. I enabled the 5th pstate and set it to 1.0V and 400 Mhz, and it seem to work just fine.However, I have a couple of questions:
1) In the docs you wrote that it is needed to disable the system frequency scaler. But are powernow / acpi pstate kernel drivers still needed or not? Because I'm running a kernel tuned for my hardware and I would be happy to drop some more code.
2) I guess the 5th pstate needs to be reenabled after every reboot. What about suspend/resume? Does the scaler automatically restore settings? Does it need to be restarted?
Thanks again

Never mind for 2), I found by myself that it is the same as rebooting.

[blackshard]

Hi blackshard, I just tested the wonderful pstate unlocking function. I enabled the 5th pstate and set it to 1.0V and 400 Mhz, and it seem to work just fine.However, I have a couple of questions:
1) In the docs you wrote that it is needed to disable the system frequency scaler. But are powernow / acpi pstate kernel drivers still needed or not? Because I'm running a kernel tuned for my hardware and I would be happy to drop some more code.
2) I guess the 5th pstate needs to be reenabled after every reboot. What about suspend/resume? Does the scaler automatically restore settings? Does it need to be restarted?
Thanks again

Well, I won't mind about 2)

About first question, tpc directly instructs the processor to jump to a pstate, so in theory acpi and powernow kernel drivers are not needed.
Also I noticed (but I can be wrong) that Phenoms II and Athlons II don't scale frequency per-core in Linux (the same happens in Windows too). TPC scaler instead is programmed to change frequency per-core, so it could be interesting to evaluate power usage with some single-threaded benchmarks. I hope to do some tests as soon as I can.

[kbios]

Well, I won't mind about 2)

About first question, tpc directly instructs the processor to jump to a pstate, so in theory acpi and powernow kernel drivers are not needed.
Also I noticed (but I can be wrong) that Phenoms II and Athlons II don't scale frequency per-core in Linux (the same happens in Windows too). TPC scaler instead is programmed to change frequency per-core, so it could be interesting to evaluate power usage with some single-threaded benchmarks. I hope to do some tests as soon as I can.

Thanks for your answer. At least on my system, per-core frequency scaling seems supported by the powernow driver. But you're right that AMD docs state that Phenom II would scale all the cores together to avoid slowing down multithreaded apps. These are the misteries of computers

[blackshard]

Thanks for your answer. At least on my system, per-core frequency scaling seems supported by the powernow driver. But you're right that AMD docs state that Phenom II would scale all the cores together to avoid slowing down multithreaded apps. These are the misteries of computers

Well this is a known problem of microsoft windows scheduler. It caused the infamous "Phenom I cool&quite Bug", which caused single threaded apps slowdowns. Ironically that "bug" was caused by the more refined phenom power management, and was addressed by AMD in Phenom II processors forcing all the cores to have the same frequency, even if that is not necessary.

Read here, if you want to go in details:

http://www.anandtech.com/show/2559/3

Anyway, I suggest to use the -CM switch to check if your powernow driver is scaling frequency per-core: usually utilities claim that this is being done, but actually the hardware do the job in a different way. -CM switch will tell you the current pstate for each core. If they switch pstate concurrently, your powernow driver is not changing frequency per-core.