Announcement

Collapse
No announcement yet.

PowerTop, AMD CPUFreq CPPC & Other Power Tests From The Ryzen 9 3900X On Linux

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

  • #11
    Originally posted by Linuxxx View Post
    Michael
    Could You please also do a test with the "schedutil" governor, since it has become very clear now that this is the future & will be the only option left in Linux!



    https://lkml.org/lkml/2019/7/13/86
    Hmmm actually did a governor comparison in July but looks like I hadn't gotten around to publishing the results yet, will do that soon.

    Hadn't seen Peter's comments, interesting. Thanks.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #12
      Using Archlinux and kernel 5.3.0-rc3 (needed for RX 5700 patches from "amd-staging-drm-next" branch [https://cgit.freedesktop.org/~agd5f/....4-2019-08-30]) it makes no difference for me using "schedutil" or "performance" governor. So far I wasn't able to reduce power consumption for my 3900X system that much while trying different settings. Using "powertop" and setting (most) "bad" settings to "good" I was at least able to reduce idle power consumption for about 8-10W. For the hard drives I used "med_power_with_dipm" power management policy instead of "min_power" as recommended in the Archlinux wiki (https://wiki.archlinux.org/index.php/Power_management). But it gives you basically the same power savings.

      I also have a Sapphire Pulse RX 5700 XT graphics card and that one is also using way more power in idle then it should. While in console (KMS enabled) it uses around 8W which is expected. But if I start KDE/Plasma with X it uses around 33-35W while idle and always uses highest frequency and I haven't found a way to get this down. Regarding this issue here are two links for other people who might have similar problems:a
      https://bugs.freedesktop.org/show_bug.cgi?id=111482
      https://bbs.archlinux.org/viewtopic.php?id=247667

      Comment


      • #13
        Originally posted by shmerl View Post
        Some also suggested, that it could be bugs in the motherboard firmware's handling of ACPI. Do you have this in dmesg?

        Code:
        ACPI: [Firmware Bug]: BIOS _OSI(Linux) query
        If yes, possibly ACPI isn't working as intended. Which can result in all kind of power related issues. So you can try overriding the name, making firmware think it's Windows. See: https://wiki.archlinux.org/index.php/DSDT

        For example I get the above on Asrock X370 Taichi, but not on X570 one.
        I got this same message on a Intel powered (Ivy Bridge i5) Thinkpad T430. And that is a very well supported system on Linux. As Dar13 commented above, doesn't look like is anything serious.

        Comment


        • #14
          @Michael: I think the higher idle power usage against windows is interesting to investigate. However the higher usage under load seems logical, because it goes along with higher performance. Maybe only windows has this problem of not reaching the boost speeds as often, while linux does and thus consumes more power.

          Comment


          • #15
            Originally posted by tomtomme View Post
            @Michael: I think the higher idle power usage against windows is interesting to investigate. However the higher usage under load seems logical, because it goes along with higher performance. Maybe only windows has this problem of not reaching the boost speeds as often, while linux does and thus consumes more power.
            I expect that both idle and full-load behave the same or almost on both linux and windows. Boost speeds are controlled by processor, and if we suppose a full-load workload which uses all the cores (otherwise it would not be full-load) the boost speeds should be the same.

            People could also check indirect hints, like the CPU thermals in windows and linux: if the CPU temperature is the same or almost the same in both OSes, then the CPU is consuming the same amount of energy thus the power delta has to be searched elsewhere. (It would be ideal to track the current intensity draw by the CPU itself, but it is not easy task without proper equipment...)

            Comment


            • #16
              I still assume this is a motherboard/chipset driver issue.

              Comment

              Working...
              X