Laptop Battery Management
For some years the house Lenovo T400 laptop has gone without a dependable battery pack. The existing battery pack was good enough to avoid an abrupt shutdown when the AC adapter was accidentally disconnected, but little more.
Lo and behold, recently the laptop received a new 6-cell battery pack. The output of upower -i /org/freedesktop/UPower/devices/battery_BAT0 indicates the battery pack’s energy-full-design is rated at 57.72 Wh and energy-full capacity at 56.16 Wh.
Lost in time and memory is what kind of discharge rate is normal for this device. Noticeable was with KDE and Ethernet (no wireless radio), the actual usage of the new battery pack lasted at best about 2.5 hours before witnessing related bells and whistles about low battery life or enjoying an abrupt shutdown.
Browsing the web found many people suffering low battery life with Linux, especially when the laptop originally came with Windows having a longer battery life.
Without comparable observations, the next route seemed to be some drainage tests. How long would the new battery last under different usage conditions until reaching 10% to 20% capacity? The T400 battery status LED turns orange at about 20% capacity. The LED is a dependable warning to grab the AC adapter.
The first round of tests were without X and idling at a console command prompt. Console (setterm) screen blanking was set to trigger at 5 minutes.
The tests alternated with and without the wireless radio being active. Unknown and untested is how much the wireless radio drains the battery. The powertop utility provided no helpful clues.
Not monitored closely was the CPU fan speed affected by CPU temperature. Depending on environment temperature, the laptop CPU temperature fluctuated between tests by several degrees and affected the CPU fan speed. How much this affects battery drainage is unknown.
Despite the unscientific approach and variables, one component notably influenced the results — the screen.
Battery life was about 5 hours when idling at a command prompt with screen blanking. Battery capacity drained at about 18% per hour. Without screen blanking the battery lasted about 3 hours and battery drainage was about 30% per hour.
Launch a desktop environment with full brightness and battery drainage was about 33% per hour.
Screen brightness often is cited as affecting battery life. Most if not all of the various desktop environments support screen brightness controls when using the battery. Using the desktop controls seems sane, but there is a fine line with how much a screen can be dimmed to impede battery drainage without hindering screen readability.
A screen brightness between 70% and 80% finds a desktop session is good for about 2.0 to 2.5 hours before receiving warnings about battery drain.
These tests are little different from the original 2.5 hour observation. The conclusion is screen brightness plays only a nominal role as opposed to using the screen altogether.
There are ways to nudge life from the battery pack, such as configuring CPU frequency governor with powersave. Yet that option is not palatable with KDE, despite having an SSD. Other options include disabling the wireless radio and bluetooth and not using external storage devices. Testing here suggested the desktop environment did not seem to matter nor did reducing the number of processes. There is a point of diminishing returns with these efforts.
Then there is the bewildering world of properly charging lithium ion batteries. Searching the web finds different opinions for optimal practices. To extend the lifetime and charge cycle counts, seems the general consensus is to keep the battery pack charged between roughly 30% to 85% capacity. The caveat is this means the battery pack will not last as long when actually being used.
Many laptops do not provide such control. Charging the battery pack is more or less a go-no-go between 0% and 100% capacity. Older Thinkpads like the T400 can use a reverse engineered tp_smapi kernel module package to manage this threshold range. Newer kernels since 5.17 are supposed to provide such support.
KDE has options to configure these charge thresholds, but the features seem broken with Slackware 15.0 and KDE 5.23.5. Modifying the rc.modules.local boot script resolves the problem.
Probably this type of configuration is fine, but if a full 100% charge is desired then clunky manual intervention is required to disable the thresholds and force the charging circuitry out of pending-charge mode. For the T400 the required litany seems to be to 1) disable the tp_smapi kernel module, 2) power down, 3) remove the battery pack, 4) press the power button for 15 seconds, 5) install the battery pack, 6) boot, and 7) charge to 100%.
Which is more helpful? Extending the overall lifetime and charge cycle counts or having longer battery sessions? If using the battery mostly for short periods and the battery can be charged frequently throughout the day, such as intermittent tasks performed away from the office desk, then perhaps the former. If routine access to the AC adapter is limited during the day, such as field trips, then perhaps the latter.
Altogether, the experimenting seems to imply that with this specific battery pack, roughly 2 to 2.5 hours is about the best that can be achieved when using any kind of GUI desktop or energy management configuration.
Posted: Category: Usability Tagged: General