Re: [e-users] Battery Monitor module source of excessively high CPU usage trouble
On Tue, 26 Feb 2008 12:11:28 -0600 "Paul Johnson" <[EMAIL PROTECTED]> babbled: > On Fri, Feb 22, 2008 at 11:39 PM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Thu, 21 Feb 2008 12:27:23 -0600 "Paul Johnson" <[EMAIL PROTECTED]> > > babbled: > > > > it could be old e config and the battery module is polling really fast: > > > > 1. rm -rf ~/.e > > 2. start e and see. > > > > > note - NOTHING has changed with e17'sw battery polling for acpi beyond > > polling frequency above to reduce wakeups. > > > > > > > In this Dell D820 laptop, I have 2 batteries. One is the usual, one > > > is in the so-called "external bay" and it can be swapped for a CDROM. > > > I should have realized E was having trouble with this because the > > > battery monitor reported nutty values like 143% and it constantly told > > > me my battery was almost out of power. Removing the battery module > > > solves the CPU problem. What a relief. > > > > the 143% is likely due to acpi simply being broken in what it reports. go > > to /proc/acpi/battery/ and check the contents of files for yourself. > > > > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > > I think you might be mistaken here. Something is messed up because > of the 2 batteries. > > The gnome-power-manager is running in the gnome panel and reports 98% > overall power and about 5 hours left. That is correct, in my > experience. > > I started the kde3 panel and in there, at the same time. I click to > open it and see it spots 2 batteries, one at 100% and one at 89%, > however if I hover the mouse without clicking, it reports only on the > smaller battery that is actually powering the system. It says 96% with > 1:20 minutes remaining. 96% may be just a weird average of the ACPI > values, I don't know how they calculate it. > > The E battery monitor says, at the same time 104% and 1:27 remaining. > That's just not right. > > I have been checking /proc/acpi and I think gnome-power is correct, E > battery is not: actually it is - e is using "last full capacity" as full capacity. you actually exceeded it: design capacity: 7800 mAh last full capacity: 6959 mAh remaining capacity: 7800 mAh on 1 battery. and the other: design capacity: 4200 mAh last full capacity: 3137 mAh remaining capacity: 2812 mAh now here is what the logic is. as you charge and discharge batteries, they will probably not store as much capacity anymore - thus their full capacity will go down over time. so they may never charge over 90% for example - or 80% once they are very old (compared to design capacity). that's the theory anyway. so over time the e battery calculations try and account for this. 100% is the max that the battery now thinks is "full" capacity. somehow u have exceeded it. that's why you get the numbers you do. gnome and kde are using design capacity as the 100% mark - e is using last full capacity as the 100% mark. of course this relies on your battery measuring this accurately and reporting it accurately. it would seem that is not the case. remember. "last full capacity" is what the battery internal electronics (it literally has a small microchip in there and some storage) reports as what *IT* thinks its current maximum capacity is (it can probably no longer reach the original factory design levels). so e is just looking at 100% full of a battery differently. 100% is 100% of what the battery thinks it can do now. not 100% of the theoretical maximum charge it could do if 100% brand new and perfect. gnome and kde assume perfect batteries and you may find over time some batteries will then never get to 100%. your battery has somehow lost/screwed its calibration maybe and you are just seeing this in E. > $ cat /proc/acpi/battery/BAT*/* > alarm: 780 mAh > present: yes > design capacity: 7800 mAh > last full capacity: 6959 mAh > battery technology: rechargeable > design voltage: 11100 mV > design capacity warning: 780 mAh > design capacity low: 236 mAh > capacity granularity 1: 78 mAh > capacity granularity 2: 78 mAh > model number:DELL YD6236 > serial number: 1977 > battery type:LION > OEM info:SMP > present: yes > capacity state: ok > charging state: charged > present rate:1 mA > remaining capacity: 7800 mAh > present voltage: 12959 mV > alarm: 420 mAh > present: yes > design capacity: 4200 mAh > last full capacity: 3137 mAh > battery technology: rechargeable > design voltage: 11100 mV > design capacity warning: 420 mAh > design capacity low: 127 mAh > capacity granularity 1: 42 mAh > capacity granularity 2: 42 mAh > model number:DELL M7 > serial number: 641 > battery type:LiP > OEM info:Sony > present:
Re: [e-users] Battery Monitor module source of excessively high CPU usage trouble
On Fri, Feb 22, 2008 at 11:39 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Thu, 21 Feb 2008 12:27:23 -0600 "Paul Johnson" <[EMAIL PROTECTED]> > babbled: > > it could be old e config and the battery module is polling really fast: > > 1. rm -rf ~/.e > 2. start e and see. > > note - NOTHING has changed with e17'sw battery polling for acpi beyond > polling > frequency above to reduce wakeups. > > > > In this Dell D820 laptop, I have 2 batteries. One is the usual, one > > is in the so-called "external bay" and it can be swapped for a CDROM. > > I should have realized E was having trouble with this because the > > battery monitor reported nutty values like 143% and it constantly told > > me my battery was almost out of power. Removing the battery module > > solves the CPU problem. What a relief. > > the 143% is likely due to acpi simply being broken in what it reports. go > to /proc/acpi/battery/ and check the contents of files for yourself. > > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > I think you might be mistaken here. Something is messed up because of the 2 batteries. The gnome-power-manager is running in the gnome panel and reports 98% overall power and about 5 hours left. That is correct, in my experience. I started the kde3 panel and in there, at the same time. I click to open it and see it spots 2 batteries, one at 100% and one at 89%, however if I hover the mouse without clicking, it reports only on the smaller battery that is actually powering the system. It says 96% with 1:20 minutes remaining. 96% may be just a weird average of the ACPI values, I don't know how they calculate it. The E battery monitor says, at the same time 104% and 1:27 remaining. That's just not right. I have been checking /proc/acpi and I think gnome-power is correct, E battery is not: $ cat /proc/acpi/battery/BAT*/* alarm: 780 mAh present: yes design capacity: 7800 mAh last full capacity: 6959 mAh battery technology: rechargeable design voltage: 11100 mV design capacity warning: 780 mAh design capacity low: 236 mAh capacity granularity 1: 78 mAh capacity granularity 2: 78 mAh model number:DELL YD6236 serial number: 1977 battery type:LION OEM info:SMP present: yes capacity state: ok charging state: charged present rate:1 mA remaining capacity: 7800 mAh present voltage: 12959 mV alarm: 420 mAh present: yes design capacity: 4200 mAh last full capacity: 3137 mAh battery technology: rechargeable design voltage: 11100 mV design capacity warning: 420 mAh design capacity low: 127 mAh capacity granularity 1: 42 mAh capacity granularity 2: 42 mAh model number:DELL M7 serial number: 641 battery type:LiP OEM info:Sony present: yes capacity state: ok charging state: discharging present rate:1921 mA remaining capacity: 2812 mAh present voltage: 11278 mV -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Battery Monitor module source of excessively high CPU usage trouble
On Thu, 21 Feb 2008 12:27:23 -0600 "Paul Johnson" <[EMAIL PROTECTED]> babbled: it could be old e config and the battery module is polling really fast: 1. rm -rf ~/.e 2. start e and see. other than that e is querying your battery for information likely via /proc/acpi/... or possibly another one of the battery interfaces. on some systems a poll is very expensive - possibly due to acpi being slow to respond in the virtual machine or complex, or buggy - it could be that the way the battery module gets acpi info is not efficient (it gets both info AND state each poll - info in theory could be fetched once only and kept, but i have not checked). note - NOTHING has changed with e17'sw battery polling for acpi beyond polling frequency above to reduce wakeups. > I installed E DR17 yesterday (with the help of Prof K's RPMS and > advice) and was troubled that it was using 40-80% of the system CPU, > even if the PC was sitting idle. I started searching posts in this > list and saw Raster's blog, which (2 years ago) showed that E with no > modules was very fast and light. But on my system, it was bloated and > sometimes slow. > > What the hell? > > I removed modules one by one until the CPU usage dropped into the > normal (less than 5% range) and, guess what (drum roll please): > > The battery module was the culprit! > > In this Dell D820 laptop, I have 2 batteries. One is the usual, one > is in the so-called "external bay" and it can be swapped for a CDROM. > I should have realized E was having trouble with this because the > battery monitor reported nutty values like 143% and it constantly told > me my battery was almost out of power. Removing the battery module > solves the CPU problem. What a relief. the 143% is likely due to acpi simply being broken in what it reports. go to /proc/acpi/battery/ and check the contents of files for yourself. > I realized I can run "gnome-panel" or the KDE kicker on one side, and > the E shelf on the other, and can use the battery monitor from those > other programs. > > I did remove the second battery and try the battery module again, but > it still showed high CPU usage. So I don't know for sure what to > conclude. Perhaps the whole framework of the motherboard & chassis > has it confused? > > If any developers want more information to investigate this, or you > want me to file a formal bug report (in case this is not known > already) I will do. > > pj > > > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Battery Monitor module source of excessively high CPU usage trouble
On Thu, Feb 21, 2008 at 12:27:23PM -0600, Paul Johnson wrote: > I did remove the second battery and try the battery module again, but > it still showed high CPU usage. So I don't know for sure what to > conclude. Perhaps the whole framework of the motherboard & chassis > has it confused? I have a D820 with a single 9-cell battery and the battery module has always returned mostly correct values, so I can vouch that there's not some major ACPI issue on your box. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Battery Monitor module source of excessively high CPU usage trouble
On Thu, 21 Feb 2008 12:27:23 -0600 "Paul Johnson" <[EMAIL PROTECTED]> wrote: > I installed E DR17 yesterday (with the help of Prof K's RPMS and > advice) and was troubled that it was using 40-80% of the system CPU, > even if the PC was sitting idle. I started searching posts in this > list and saw Raster's blog, which (2 years ago) showed that E with no > modules was very fast and light. But on my system, it was bloated and > sometimes slow. > > What the hell? > > I removed modules one by one until the CPU usage dropped into the > normal (less than 5% range) and, guess what (drum roll please): > > The battery module was the culprit! > > In this Dell D820 laptop, I have 2 batteries. One is the usual, one > is in the so-called "external bay" and it can be swapped for a CDROM. > I should have realized E was having trouble with this because the > battery monitor reported nutty values like 143% and it constantly told > me my battery was almost out of power. Removing the battery module > solves the CPU problem. What a relief. > > I realized I can run "gnome-panel" or the KDE kicker on one side, and > the E shelf on the other, and can use the battery monitor from those > other programs. > > I did remove the second battery and try the battery module again, but > it still showed high CPU usage. So I don't know for sure what to > conclude. Perhaps the whole framework of the motherboard & chassis > has it confused? > > If any developers want more information to investigate this, or you > want me to file a formal bug report (in case this is not known > already) I will do. > > pj The configuration for the battery monitor was changed recently to measure the update interval in ticks (not sure exactly what these are) rather than in seconds as it was before. The value wasn't changed though, so if your update interval used to be one second, it's now one tick, which is ridiculously high. Try increasing the update interval in the battery module config, that should fix the issue. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] Battery Monitor module source of excessively high CPU usage trouble
I installed E DR17 yesterday (with the help of Prof K's RPMS and advice) and was troubled that it was using 40-80% of the system CPU, even if the PC was sitting idle. I started searching posts in this list and saw Raster's blog, which (2 years ago) showed that E with no modules was very fast and light. But on my system, it was bloated and sometimes slow. What the hell? I removed modules one by one until the CPU usage dropped into the normal (less than 5% range) and, guess what (drum roll please): The battery module was the culprit! In this Dell D820 laptop, I have 2 batteries. One is the usual, one is in the so-called "external bay" and it can be swapped for a CDROM. I should have realized E was having trouble with this because the battery monitor reported nutty values like 143% and it constantly told me my battery was almost out of power. Removing the battery module solves the CPU problem. What a relief. I realized I can run "gnome-panel" or the KDE kicker on one side, and the E shelf on the other, and can use the battery monitor from those other programs. I did remove the second battery and try the battery module again, but it still showed high CPU usage. So I don't know for sure what to conclude. Perhaps the whole framework of the motherboard & chassis has it confused? If any developers want more information to investigate this, or you want me to file a formal bug report (in case this is not known already) I will do. pj -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
