Announcement

Collapse
No announcement yet.

New tool for undervolt/overclock AMD K8L and K10 processors

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by zz13 View Post
    Code:
    Turion Power States Optimization and Control - by blackshard - v0.30
    Detected CPU:
    Family: 0xf		Model: 0x4		Stepping: 0x3
    Extended Family: 0x10	Extended Model: 0x4
    Package Type: 0x1	BrandId: 0x1ad6	
    Detected Physical Cores: 4
    Detected processor: AMD Family 10h Processor
    Processor has 4 cores
    Processor has 5 p-states
    
    Power States table:
    -- Core 0
    core 0 pstate 0 - En:1 VID:22 FID:14 DID:0 Freq:3000 VCore: 1.0000
    core 0 pstate 1 - En:1 VID:30 FID:7 DID:0 Freq:2300 VCore: 0.8000
    core 0 pstate 2 - En:1 VID:32 FID:2 DID:0 Freq:1800 VCore: 0.7625
    core 0 pstate 3 - En:1 VID:52 FID:0 DID:1 Freq:800 VCore: 0.5125
    core 0 pstate 4 - En:0 VID:52 FID:0 DID:1 Freq:800 VCore: 0.5125
    
    >>>other cores have identical info, clipped
     
    Processor Maximum PState: 3
    Processor Startup PState: 3
    Processor Maximum Operating Frequency: 3000 MHz
    
    Minimum allowed VID: 63 (0.375v) - Maximum allowed VID 22 (1.000v)
    Processor AltVID: 34 (0.738v)
    Northbridge Power States table:
    PState 0 - NbVid 22 (1.0000) NbDid 0 NbFid 4
    PState 1 - NbVid 30 (0.8000) NbDid 0 NbFid 4
    PState 2 - NbVid 32 (0.7625) NbDid 0 NbFid 4
    PState 3 - NbVid 52 (0.5125) NbDid 0 NbFid 4
    PState 4 - NbVid 52 (0.5125) NbDid 0 NbFid 4
    Northbridge Maximum frequency: 2000
    * Warning: PVI mode is set. Northbridge voltage is used for processor voltage at given pstates!
    * Changing Northbridge voltage changes core voltage too.
    
    Core 0 C1E CMP halt bit is disabled
    Core 1 C1E CMP halt bit is disabled
    Core 2 C1E CMP halt bit is disabled
    Core 3 C1E CMP halt bit is disabled
    
    Voltage Regulator Slamming time register: 4
    Voltage Regulator Step Up Ramp Time: 8
    Voltage Regulator Step Down Ramp Time: 8
    Processor is using Parallel VID Interface (probably Single Plane mode)
    Processor PState Identifier: 0x3
    PSI_L bit not enabled
    Value 0.5125 on pstate 3 under Windows 85W (voltage dropped) and Linux (no effect) 105W measured with power consumption meter.
    Mmmh...
    First of all it looks really strange to me that your processor is running at 3.0 Ghz with 1.000 voltage. Does k10stat tell the same power state table as tpc does? I'm worried about some voltage conversion errors (even if I double checked them).

    BTW, you should let the processor do a pstate transition to really apply new settings. I explain: when you use tpc and change the core voltage, the processor has to reenter in that pstate to apply new settings. When the pstate changed is the slowest pstate (the pstate used when the processor goes idling) you need to put a load to let the processor go out of the pstate and then reenter.

    Unfortunately I had no chance to test the behaviour on a AM2 motherboard with a AM2+ processor, so I can't be more detailed on this.

    Comment


    • #77
      Originally posted by blackshard View Post
      Mmmh...
      First of all it looks really strange to me that your processor is running at 3.0 Ghz with 1.000 voltage. Does k10stat tell the same power state table as tpc does? I'm worried about some voltage conversion errors (even if I double checked them).
      Well, this is the thing I have tried to tell. Tpc reports unlogical values. K10stat reports logical and probably correct values. By the way, also other Linux tool k10ctl have this wrong value problem.

      Originally posted by blackshard View Post
      BTW, you should let the processor do a pstate transition to really apply new settings.
      There has been transitions but still no effect.

      Comment


      • #78
        Mmmh... what kind of motherboard do you have?

        Anyway, I'm not really sure if the problem is related to Serial VID and Parallel VID settings.

        Maybe you can try to force Serial VID and see if voltages became coherent with k10stat.

        If you want to try, open K10Processor.cpp file and change line 473 from:

        Code:
        if (miscReg==0) return false; else return true;
        to

        Code:
        return false;
        According to the SVI VID table, VID 22 (your maximum voltage accepted) is equal to 1.2750v, and I think it is the correct value there. Can you confirm?

        Comment


        • #79
          Originally posted by blackshard View Post
          Mmmh... what kind of motherboard do you have?
          Asus M2NPV-MX

          Originally posted by blackshard View Post
          Anyway, I'm not really sure if the problem is related to Serial VID and Parallel VID settings.

          Maybe you can try to force Serial VID and see if voltages became coherent with k10stat.

          If you want to try, open K10Processor.cpp file and change line 473 ...
          With the code change the values are identical to K10stat.

          Originally posted by blackshard View Post
          According to the SVI VID table, VID 22 (your maximum voltage accepted) is equal to 1.2750v, and I think it is the correct value there. Can you confirm?
          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.

          Comment


          • #80
            Originally posted by blackshard View Post
            Mmmh... what kind of motherboard do you have?

            Anyway, I'm not really sure if the problem is related to Serial VID and Parallel VID settings.

            Maybe you can try to force Serial VID and see if voltages became coherent with k10stat.

            If you want to try, open K10Processor.cpp file and change line 473 from:

            Code:
            if (miscReg==0) return false; else return true;
            to

            Code:
            return false;
            According to the SVI VID table, VID 22 (your maximum voltage accepted) is equal to 1.2750v, and I think it is the correct value there. Can you confirm?
            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
            Code:
            Turion Power States Optimization and Control - by blackshard - v0.30
            Detected CPU:
            Family: 0xf             Model: 0x4              Stepping: 0x2
            Extended Family: 0x10   Extended Model: 0x4
            Package Type: 0x1       BrandId: 0x1a86
            Detected Physical Cores: 4
            Detected processor: AMD Family 10h Processor
            Processor has 4 cores
            Processor has 5 p-states
            
            Power States table:
            -- Core 0
            core 0 pstate 0 - En:1 VID:11 FID:19 DID:0 Freq:3500 VCore: 1.4125
            core 0 pstate 1 - En:1 VID:24 FID:7 DID:0 Freq:2300 VCore: 1.2500
            core 0 pstate 2 - En:1 VID:32 FID:2 DID:0 Freq:1800 VCore: 1.1500
            core 0 pstate 3 - En:1 VID:32 FID:0 DID:1 Freq:800 VCore: 1.1500
            core 0 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:1600 VCore: 1.5500
            -- Core 1
            core 1 pstate 0 - En:1 VID:11 FID:19 DID:0 Freq:3500 VCore: 1.4125
            core 1 pstate 1 - En:1 VID:24 FID:7 DID:0 Freq:2300 VCore: 1.2500
            core 1 pstate 2 - En:1 VID:32 FID:2 DID:0 Freq:1800 VCore: 1.1500
            core 1 pstate 3 - En:1 VID:32 FID:0 DID:1 Freq:800 VCore: 1.1500
            core 1 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:1600 VCore: 1.5500
            -- Core 2
            core 2 pstate 0 - En:1 VID:11 FID:19 DID:0 Freq:3500 VCore: 1.4125
            core 2 pstate 1 - En:1 VID:24 FID:7 DID:0 Freq:2300 VCore: 1.2500
            core 2 pstate 2 - En:1 VID:32 FID:2 DID:0 Freq:1800 VCore: 1.1500
            core 2 pstate 3 - En:1 VID:32 FID:0 DID:1 Freq:800 VCore: 1.1500
            core 2 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:1600 VCore: 1.5500
            -- Core 3
            core 3 pstate 0 - En:1 VID:11 FID:19 DID:0 Freq:3500 VCore: 1.4125
            core 3 pstate 1 - En:1 VID:24 FID:7 DID:0 Freq:2300 VCore: 1.2500
            core 3 pstate 2 - En:1 VID:32 FID:2 DID:0 Freq:1800 VCore: 1.1500
            core 3 pstate 3 - En:1 VID:32 FID:0 DID:1 Freq:800 VCore: 1.1500
            core 3 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:1600 VCore: 1.5500
            Processor Maximum PState: 3
            Processor Startup PState: 3
            Processor Maximum Operating Frequency: No maximum defined. Unlocked multiplier.
            
            Minimum allowed VID: 123 (0.013v) - Maximum allowed VID 0 (1.550v)
            Processor AltVID: 34 (1.125v)
            Northbridge Power States table:
            PState 0 - NbVid 11 (1.4125) NbDid 0 NbFid 4
            PState 1 - NbVid 24 (1.2500) NbDid 0 NbFid 4
            PState 2 - NbVid 32 (1.1500) NbDid 0 NbFid 4
            PState 3 - NbVid 32 (1.1500) NbDid 0 NbFid 4
            PState 4 - NbVid 0 (1.5500) NbDid 0 NbFid 4
            Northbridge Maximum frequency: 800
            
            Core 0 C1E CMP halt bit is disabled
            Core 1 C1E CMP halt bit is disabled
            Core 2 C1E CMP halt bit is disabled
            Core 3 C1E CMP halt bit is disabled
            
            Voltage Regulator Slamming time register: 4
            Voltage Regulator Step Up Ramp Time: 8
            Voltage Regulator Step Down Ramp Time: 8
            Processor is using Serial VID Interface (probably Dual Plane mode)
            Processor PState Identifier: 0x2
            PSI_L bit not enabled
            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

            Comment


            • #81
              Originally posted by zz13 View Post
              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.

              Comment


              • #82
                Originally posted by kbios View Post
                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.

                Comment


                • #83
                  Originally posted by blackshard View Post
                  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".

                  Comment


                  • #84
                    Originally posted by kbios View Post
                    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.

                    Comment


                    • #85
                      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 :/

                      Comment


                      • #86
                        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

                        Comment


                        • #87
                          Originally posted by kbios View Post
                          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.

                          Comment


                          • #88
                            Originally posted by kbios View Post
                            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.

                            Comment


                            • #89
                              Originally posted by blackshard View Post
                              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

                              Comment


                              • #90
                                Originally posted by kbios View Post
                                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.

                                Comment

                                Working...
                                X