Announcement

Collapse
No announcement yet.

The Linux Kernel Power Problems On Older Desktop Hardware

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

  • fewt
    replied
    Originally posted by deanjo View Post
    "Works for me" is never proof of something working fine for everyone and the people that are experiencing the issue are seeing differences in battery life by simply swapping the kernel for an older one.
    I agree, however "WorksForMe" isn't at play here, since I have pretty extensive knowledge of power saving techniques on this platform.

    I did write Jupiter after all.

    People aren't seeing differences in battery life by simply swapping the kernel, if you look at the bug report on Launchpad the majority of them would save battery life simply by properly testing.

    Most of the people confirming the "bug" have web browsers and other applications open that of course cause wakeups. That's simply what applications do.

    Don't make assumptions.

    Leave a comment:


  • deanjo
    replied
    Originally posted by fewt View Post
    Yes, I have used my netbook for 10 hours with kernel 2.6.39 and yes I still had battery left afterwards.
    "Works for me" is never proof of something working fine for everyone and the people that are experiencing the issue are seeing differences in battery life by simply swapping the kernel for an older one.

    Leave a comment:


  • ioannis
    replied
    Originally posted by Jimmy View Post
    The first graph is completely meaningless because it seems that there are different numbers of idle samples to busy samples between kernels.

    Of course if you have more idle points than busy points you're going to have a lower average power. The idle points vs the Busy points are easy to see from the graph. Now look at the ratio of I to B:

    Code:
    KV      I to B     I/B     Av pwr
    ------===========================
    2.6.34  14 to 1    14      54
    2.6.35  10 to 3     3.3    59.3
    2.6.36   9 to 1     9      57.6
    2.6.37   8 to 3     2.6    60.4
    2.6.38   9 to 4     2.25   65.6
    2.6.39  10 to 4     2.5    66.4
    3.0.00   8 to 5     1.6    70.5
    Now sort them by the I/B and notice the average power magically gets sorted too (except for one point which is probably close enough to be within the margin of error).

    Code:
    KV      I to B     I/B     Av pwr
    ===================-----=========
    2.6.34  14 to 1    14      54
    2.6.36   9 to 1     9      57.6
    2.6.35  10 to 3     3.3    59.3
    2.6.37   8 to 3     2.6    60.4
    2.6.39  10 to 4     2.5    66.4
    2.6.38   9 to 4     2.25   65.6
    3.0.00   8 to 5     1.6    70.5
    [sarcasm]OMG the ones with a lower I/B are on a power binge!!![/sarcasm] Completely useless.

    The rest of the graphs are more interesting, mostly because they don't seem to be fundamentally flawed. However, they don't really show that power consumption is that much worse off.

    Of course since the entire article seems to hinge on the first graph...

    Exactly!!!

    and as someone else pointed out, looking at the first graph, it looks like a difference in how the speedstep is being used, i.e. enabled post 2.6.34 and tune/tweaked afterwords. Seems that 3.0 has a more 'aggressive' response to load. I don't actually see any so called power regression on the 2.6.38, at least on this hardware. If anything, .38 seems to have a more 'relaxed' recovery from idle.

    Leave a comment:


  • fewt
    replied
    oh my

    Are we still beating this dead horse? This power bug doesn't exist, and sadly I'm starting to believe it is being reported on for the sole purpose of driving hits.

    No, the sky is not falling. Yes, I have used my netbook for 10 hours with kernel 2.6.39 and yes I still had battery left afterwards.

    Time to let it go and move on, or actually spend time finding the problem instead of writing articles about it.

    Sorry to be so blunt, but people are actually believing this even though there is NO evidence that it's real.

    Leave a comment:


  • not.sure
    replied
    Originally posted by NeoBrain View Post
    Michael, with respect: You are doing binary bisecting, right?

    I mean, you've been "tracking down" this issue for ... I don't know, more than a month now. The fact that you're compiling the kernel on a slow laptop really doesn't sound like a fair excuse anymore. Or are you just still keeping the results for yourself?
    He wanted to wait til he got the power meter (last weekend) to finish bisecting all the power issues. Hopefully that also means he wants to do it properly, because then the kernel dudes might take it seriously and fix it (and I could move away from 2.6.37...)

    Leave a comment:


  • NeoBrain
    replied
    Michael, with respect: You are doing binary bisecting, right?

    I mean, you've been "tracking down" this issue for ... I don't know, more than a month now. The fact that you're compiling the kernel on a slow laptop really doesn't sound like a fair excuse anymore. Or are you just still keeping the results for yourself?

    Leave a comment:


  • Jimmy
    replied
    Useless

    The first graph is completely meaningless because it seems that there are different numbers of idle samples to busy samples between kernels.

    Of course if you have more idle points than busy points you're going to have a lower average power. The idle points vs the Busy points are easy to see from the graph. Now look at the ratio of I to B:

    Code:
    KV      I to B     I/B     Av pwr
    ------===========================
    2.6.34  14 to 1    14      54
    2.6.35  10 to 3     3.3    59.3
    2.6.36   9 to 1     9      57.6
    2.6.37   8 to 3     2.6    60.4
    2.6.38   9 to 4     2.25   65.6
    2.6.39  10 to 4     2.5    66.4
    3.0.00   8 to 5     1.6    70.5
    Now sort them by the I/B and notice the average power magically gets sorted too (except for one point which is probably close enough to be within the margin of error).

    Code:
    KV      I to B     I/B     Av pwr
    ===================-----=========
    2.6.34  14 to 1    14      54
    2.6.36   9 to 1     9      57.6
    2.6.35  10 to 3     3.3    59.3
    2.6.37   8 to 3     2.6    60.4
    2.6.39  10 to 4     2.5    66.4
    2.6.38   9 to 4     2.25   65.6
    3.0.00   8 to 5     1.6    70.5
    [sarcasm]OMG the ones with a lower I/B are on a power binge!!![/sarcasm] Completely useless.

    The rest of the graphs are more interesting, mostly because they don't seem to be fundamentally flawed. However, they don't really show that power consumption is that much worse off.

    Of course since the entire article seems to hinge on the first graph...

    Leave a comment:


  • speculatrix
    replied
    typo

    you wrote: "it shows the pre-2.5.34 kernels are consuming a vicious amount of power."

    I think you meant "the pre-2.6.34 kernels"

    ?

    Leave a comment:


  • Xilanaz
    replied
    Originally posted by kiwi_kid_aka_bod View Post
    I don't see it. The way I read that graph is that in .32 and .33 the desktop was not stepping down the power, and was going full bore all the time. In .34 this power management was introduced for the desktop. Then it looks like, from .35 onwards, the stepping up was made more sensitive to increased performance needs, going to full power. This would be to prevent people experiencing stutter, or poor experience with the system stepping up and down constantly.
    Had the exact same thought

    Leave a comment:


  • TeoLinuX
    replied
    Originally posted by kiwi_kid_aka_bod View Post

    Second on the first graph:

    I don't see it. The way I read that graph is that in .32 and .33 the desktop was not stepping down the power, and was going full bore all the time. In .34 this power management was introduced for the desktop. Then it looks like, from .35 onwards, the stepping up was made more sensitive to increased performance needs, going to full power. This would be to prevent people experiencing stutter, or poor experience with the system stepping up and down constantly.
    I totally agree

    Leave a comment:

Working...
X