Announcement

Collapse
No announcement yet.

The Linux Kernel Power Problems On Older Desktop Hardware

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

  • #16
    Originally posted by deanjo View Post
    "Most" are not all. Don't make assumptions. It is however reasonable to think that those that did have browsers open also had them open in both instances, with older kernel and new.
    Again you make assumptions. I looked at each and every comment in the bug report and discredited nearly all of them almost two weeks ago.

    From report #760131
    Comment #1 - chromium-browser, PS/2 keyboard/mouse/touchpad interrupt, thunderbird-bin, gwibber-service, ubuntuone-syncd, desktopcouch - The system is not idle, non-idle systems cannot have sub 200 wakeups, as they system is busy being used.

    Comment #10 - chrome, iwlagn - System is busy being used, and not idle.

    Comment #12 - 91 wakeups, looks pretty idle

    Comment #13 - firefox, gtk-gnash, mc, wget, grep - Not an idle system

    Comment #51 - First result, fairly idle and < 100 wakeups. Second result - gwibber, nautilus, etc - Not idle

    Comment #54 - The entire process list isn't included, invalid.

    Comment #53 - Sub 100 wakeups

    Comment #65 - The entire process list isn't included, invalid.

    Comment #66 - Chromium, Docky - System not idle

    Comment #67 - 21 wakeups

    Comment #82 - USB OPTICAL MOUSE .. USB input devices drain batteries and cause wakeups. There are other external devices connected.

    Comment #85 - PS/2 keyboard/mouse/touchpad interrupt - Not idle, and incomplete process list.

    All of the reports are using Powertop 1.13, but kernels newer than 2.6.36 (that some people were using) need 1.97.

    This report seems to be filled with comments by people that don't know how to test for issues like the one being reported. That's not a problem with the reporters, as they just don't know how to test it which isn't their fault.

    To properly test it, the system should be completely idle with all applications closed, and all external keyboards, mice, hard drives, flash drives, or whatever disconnected. You can't have a busy system and expect the processor to stay sleep, that is simply illogical.
    I know you are trying to defend the article, but this is ridiculous. Phoronix was given the benefit of the doubt, and has had plenty of time to "bisect the issue". All this article does is continue to claim that the sky is falling, but if you look outside you will find that the sky is certainly NOT falling.

    If it were we would have credible reports and not just one tinfoil hat article, and the resulting bug reports from the paranoia that it caused.

    Comment


    • #17
      Originally posted by fewt View Post
      Again you make assumptions. I looked at each and every comment in the bug report and discredited nearly all of them almost two weeks ago.

      I know you are trying to defend the article, but this is ridiculous. Phoronix was given the benefit of the doubt, and has had plenty of time to "bisect the issue". All this article does is continue to claim that the sky is falling, but if you look outside you will find that the sky is certainly NOT falling.

      If it were we would have credible reports and not just one tinfoil hat article, and the resulting bug reports from the paranoia that it caused.
      What you did is not discredit them but offered alternative options on your pure speculation. You offered your theory, nothing more. Alternatively Michael is actually doing the school work to find the reason for the regressions he is observing.

      Comment


      • #18
        Originally posted by deanjo View Post
        What you did is not discredit them but offered alternative options on your pure speculation. You offered your theory, nothing more. Alternatively Michael is actually doing the school work to find the reason for the regressions he is observing.
        By "theory" you mean practice, practice which happens to be in the realm of Linux power management.

        Something that I have deep roots in and years of experience with.

        Not to mention the thousands of users of my product that improves power savings .. on the Linux platform. None of which have filed a bug report, or made mere mention of battery life issues with any recent kernel.

        Because those issues don't exist.

        I also happen to have experience with product testing, and believe me they are all doing it wrong. There is no control group, and the test reports are all over the map. You can't confirm anything by it except that the testing itself is invalid.

        Michael has had enough time to find the issue, and he's come up empty. The closest thing we have seen to a "real" power related issue is the patch for the cpuidle bug that was pulled into 2.6.39.1.

        Too bad you don't like what I have to say but Phoronix is wrong, get over it.

        Comment


        • #19
          Originally posted by fewt View Post
          By "theory" you mean practice, practice which happens to be in the realm of Linux power management.

          Something that I have deep roots in and years of experience with.
          Sorry but as a developer going on for close to two decades now that proves nothing. All it proves is that you were unable to replicate it. We have all seen bugs in software that have spanned years but because they were hard to reproduce or to nail down as to the exact cause. For example just recently I nailed down a bug that had eluded our company for years because the combination of criteria that had to be in play for it to act up was very specific (ATI card, window frame size of 1366x682 with a button on the gui stored in png format at a specific size as well). We have had reports for years about it but until recently have been able to do absolutely nothing to fix it as the triggers had to be in the exact combination.

          Not to mention the thousands of users of my product that improves power savings .. on the Linux platform. None of which have filed a bug report, or made mere mention of battery life issues with any recent kernel.
          Again that really doesn't prove anything. Until you can 100% prove and 100% replicate each of those reports you cannot say with certainty that they don't exist.

          I also happen to have experience with product testing, and believe me they are all doing it wrong. There is no control group, and the test reports are all over the map. You can't confirm anything by it except that the testing itself is invalid.
          As do I and many others have extensive experience in product testing as well. Is the environment that these testing ideal, absolutely not but they are about as good as they are going to get without massive manpower and financial backing. It is always easier to isolate an issue in a iron clad control environment but alas the whole open development movement doesn't exactly cater to that. You make do with what you have available.

          Michael has had enough time to find the issue, and he's come up empty.
          That statement right there can be proven wrong soooooooooo many times. Not all bugs are found and isolated so quickly. You can visit any bug tracker and see clear evidence of that especially where the bug is not a P1 "we really fucked up and severely borked the system rendering it useless".

          Too bad you don't like what I have to say but Phoronix is wrong, get over it.
          Again the only thing that you have proven is that you cannot reproduce or have observed it. In any type of research that is not proof of it existing or not being there.

          Comment


          • #20
            r200

            The Radeon DRM changes in the Linux 2.6.33 kernel related to the R200 series includes 3DC compression support, support for external TMDS on older hardware, and reworked Radeon object handling.
            Nope, these are mainly for R300, nothing for R200.

            While the Radeon 9200PRO graphics card has regressed, even with the Linux 2.6.32 kernel the open-source Mesa driver and DRM do not result in a playable experience for this game at 1280 x 1024.
            r200 just regresseed with transition to KMS! Mesa regressed! If someone needs excellent GL performance, compatibility and lowest mesa/r200 bug level on R200 based cards s/he (so do I) could use UMS and mesa-7.5.2 (yep, 7.5 is 2 years old but still could be used with current X, current DDX and current kernel).

            It is all metter of software combo you (want to) run.

            Comment


            • #21
              After some long and frustrating research myself, I think the "power saga" is a non issue too. The high wake ups was caused by my own acerfand and backlight fixing scripts which set in the background polling hardware status.

              I finally came up with that conclusion after trying all possible kernels, those kernels behaves very nice on my desktop system are having ridiculously high wake ups on my laptop.

              2.6.35, 2.6.37, 2.6.39 on my desktop: 10~20 wake ups per second
              exact same kernels on laptop: 160~200 wake ups per second

              Only after installing Powertop 1.97 it was able to show that my script was constantly banging the hardware access, which causes high wake ups.

              Removing the acerfand script and backlight script makes the laptop behaves same as the desktop, 10~20 wake ups per second and 5.x watt idle power with screen on.

              I think I will post a detailed topic on the discover of the issue: It is indeed userland issue.

              Comment


              • #22
                Also to the powertop users:

                STOP RUNNING THE FRICKING WEB BROWSERS AND MOVING YOUR MOUSE LIKE CRAZY!

                It is YOU that is waking up the CPU, nothing more!

                Comment


                • #23
                  Originally posted by deanjo View Post
                  Sorry but as a developer going on for close to two decades now that proves nothing. All it proves is that you were unable to replicate it. We have all seen bugs in software that have spanned years but because they were hard to reproduce or to nail down as to the exact cause. For example just recently I nailed down a bug that had eluded our company for years because the combination of criteria that had to be in play for it to act up was very specific (ATI card, window frame size of 1366x682 with a button on the gui stored in png format at a specific size as well). We have had reports for years about it but until recently have been able to do absolutely nothing to fix it as the triggers had to be in the exact combination.
                  Unable to replicate it because it does not exist, as I indicated.

                  Originally posted by deanjo View Post
                  Again that really doesn't prove anything. Until you can 100% prove and 100% replicate each of those reports you cannot say with certainty that they don't exist.
                  The reports are useless, if you can't or are unwilling to see that then I would question anything else that you have to say in relation to the issue.

                  Originally posted by deanjo View Post
                  As do I and many others have extensive experience in product testing as well. Is the environment that these testing ideal, absolutely not but they are about as good as they are going to get without massive manpower and financial backing. It is always easier to isolate an issue in a iron clad control environment but alas the whole open development movement doesn't exactly cater to that. You make do with what you have available.
                  It doesn't take massive manpower or financial backing, it simply takes coordination. You don't get that by writing articles about the sky falling. Nor do these articles improve credibility of Phoronix.

                  Originally posted by deanjo View Post
                  That statement right there can be proven wrong soooooooooo many times. Not all bugs are found and isolated so quickly. You can visit any bug tracker and see clear evidence of that especially where the bug is not a P1 "we really fucked up and severely borked the system rendering it useless".
                  Sure, but you have to prove there is a bug first. Making wild claims does not prove that there is a bug.

                  Originally posted by deanjo View Post
                  Again the only thing that you have proven is that you cannot reproduce or have observed it. In any type of research that is not proof of it existing or not being there.
                  As I said, it doesn't exist. Making lame excuses as to why I (and others) haven't seen it doesn't really help.

                  Comment


                  • #24
                    Originally posted by fewt View Post
                    Unable to replicate it because it does not exist, as I indicated.



                    The reports are useless, if you can't or are unwilling to see that then I would question anything else that you have to say in relation to the issue.



                    It doesn't take massive manpower or financial backing, it simply takes coordination. You don't get that by writing articles about the sky falling. Nor do these articles improve credibility of Phoronix.



                    Sure, but you have to prove there is a bug first. Making wild claims does not prove that there is a bug.



                    As I said, it doesn't exist. Making lame excuses as to why I (and others) haven't seen it doesn't really help.
                    You seem to miss an extremely simple concept here. Being not able to replicate is not proof that it does not exist. It only proves that you cannot replicate it.

                    Comment


                    • #25
                      I think we have to pose some very basic requirement when collecting statistics data:

                      Which version of Powertop? Different version gives different result
                      Interacting with the machine? Invalid result
                      Having any client program running? Invalid result

                      I can see there is a lot of noise to the actual data, like samples where chrome is waking the CPU up 400 times/s, or touch pad/Mouse/PS2 is waking the CPU up 200 time/s, even a sample where nautilus is very active and doing 120/s CPU wakeup (What the hell people?), those are invalid data which should not be taken into account.

                      Unfortunately almost 90% data appeared on the internet fall into this (invalid) category. So the problem is definitely way over-reacted.

                      And even if you got the basics right, like my situation before, there are userland daemons which keeps the CPU busy. I would have never realized that a fan monitoring program is capable of waking CPU up 20-30 times per second, merely polling the sensor data. So, yeah, if you ran any third party scripts in the background, stop them.

                      Anyway, my rant goes on, learn how to use the tool first, before your data can be accepted as valid results. Don't just fire up Powertop then jerk around in the system to come up with a 1000/s wake up 'IDLE' stat, your machine is surely not frikking IDLE being jerked around by YOU.
                      Last edited by FunkyRider; 06-22-2011, 10:54 PM.

                      Comment


                      • #26
                        Originally posted by deanjo View Post
                        You seem to miss an extremely simple concept here. Being not able to replicate is not proof that it does not exist. It only proves that you cannot replicate it.
                        I haven't missed any concept. To imply that I have shows that you either don't understand my comments, or that you are too arrogant to admit that I might be right.

                        Either way, it's your problem.

                        Comment


                        • #27
                          Originally posted by fewt View Post
                          I haven't missed any concept. To imply that I have shows that you either don't understand my comments, or that you are too arrogant to admit that I might be right.

                          Either way, it's your problem.
                          I never said you might not be right, but you have not proved that it doesn't exist. You say "This power bug doesn't exist" which is an absolute answer with no possibility of any chance that you might be missing something or unable to replicate. The only one displaying arrogance is you with your self confidence that what ever results you come up with has to be the only and absolute right answer.

                          Comment


                          • #28
                            Hey fewt, where are your tests that demonstrate the power usage across kernels has not changed? Until then, you have no right to discredit others.

                            I hope to see more tests, with actual facts and science done, not petty bickering in a forum based on beliefs.

                            Comment


                            • #29
                              What is up with the unlabelled axes on these graphs? And why do some of the plots appear to stop in the middle of the graph?

                              I also fail to see the "well-known" power regression.. can anyone explain where it is on the first plot?

                              This is a very confusing article.

                              Comment


                              • #30
                                Originally posted by deanjo View Post
                                I never said you might not be right, but you have not proved that it doesn't exist. You say "This power bug doesn't exist" which is an absolute answer with no possibility of any chance that you might be missing something or unable to replicate. The only one displaying arrogance is you with your self confidence that what ever results you come up with has to be the only and absolute right answer.
                                It's no worse than Phoronix insisting that it does exist while at the same time being unable to show it. This article in particular is not conclusive on the point yet it carries the title "The Linux Kernel Power Problems On Older Desktop Hardware." Yes, that's the title even though it fails to show an actual problem with recent kernels that supposedly have some killer widespread regression.

                                Just look at that graph and tell me that the average power shown there actually can mean a damned thing if each kernel is measured differently. There clearly are more idle samples than busy samples for some kernels. The 2.6.36 kernel is apparently so good that it only uses extra power for ONE sample, the last one. Does that realllllly sound reasonable? Why does the 2.6.36 have fewer samples for that kernel than any other kernel? Did it really play the video that fast or was it cut off for some reason?

                                Comment

                                Working...
                                X