For long train journeys, the battery life is important, and as this laptop has a Pentium M processor, it should be able to modify its frequency according to load, so that when it's got nothing much to do, it runs slower and cooler, and draws less power from the battery. When it gets some work to do, it can step up the power a bit, and get the job done faster, but for most of the train journey it's probably just idling. It would be nice to check that this is going on properly.
The first attempt to see what's going on comes from the file
/proc/cpuinfo which lists the CPU frequency
as 1.6 GHz, as expected. However, oddly, nothing seems to have any effect on this file, so perhaps it just lists the
maximum, or default frequency, rather than the actual, current operating frequency.
model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 6 cpu MHz : 1598.768
The next clue leads us to the file
/proc/acpi/processor/CPU0/throttling, which shows the so-called 'throttling state'
of the CPU. Sounds like exactly what we're looking for:
$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87%
This tells us that out of the 8 throttling states available, the CPU is currently in state 0, which means 0% throttling (that is, maximum speed). But that was with mains power, now let's unplug the mains and see what it does on battery:
$ cat /proc/acpi/processor/CPU0/throttling state count: 8 active state: T2 states: T0: 00% T1: 12% *T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87%
So when powered from the battery it operates in state 2, with 25% throttling, so three-quarters speed. What's even better
with this, by
echoing a number to this file, you can manually set the throttling state, for example:
$ echo -n 5 > /proc/acpi/processor/CPU0/throttling
sets the throttling state to 5, and this can be confirmed by repeating the
cat command above. So what effect does
this throttling have?
Firstly, it has a dramatic effect on processor speed, at least as measured by the distributed.net client. By running the benchmark option on this program for the 8 different throttling states, it's obvious that this throttling has a large effect on system performance.
|Graph of benchmark speeds (thousands of keys per second) against CPU throttling state|
So, given that this throttling speeds up and slows down the processor, it would seem reasonable to assume that it would have an effect on the battery life (which is, after all, the whole point of throttling). So I plotted the life of the battery while the CPU was in throttling state 0, and again with state 7. I expected to see a difference, but in fact, there is absolutely no difference measurable in any way. Odd.
|Graph of reported battery charge against time, for state 0 and state 7|
The final 'kink' in the otherwise surprisingly linear line is probably due to some memory effects in the battery, and the slight difference between the two lines at this point is perhaps due to differences in the time for which the battery was charged and so on. However this difference is so small as to be negligible - frequency-stepping CPUs would not have been invented and configured just to give an extra 10 minutes' battery life Something else is going on here.
There's a daemon called
cpufreqd which should do the automatic switching based on processor load, power input (mains or battery),
and current battery state, based on a configuration file. According to its debug messages it seems to be reacting properly to all the
triggers, and apparently changing state, but this state-changing has no visible affect on the throttling state or the
file, and again no difference to the battery life, whether this daemon is running or not.
I was advised to install and run a program called
gkrellm, which monitors and displays various aspects of the system,
including processor load, numbers of users and processes, disk space usage and lots of other stuff. However, the CPU frequency bit
(as well as several others) come in a separate package called
gkrellm-plugins. With that installed and added to the
display, we see information like the picture on the right:
As it's running on mains power (note the little plug icon in the bottom left), the frequency is reported as 1.6GHz (near enough) even though the CPU load is next to nothing. Going from top to bottom, the information displayed here (highly configurable if you want) shows CPU load over time (right side is now), CPU frequency, hard drive access over time, ethernet access over time (including current data rate, 6 kilobytes per second), memory usage, battery state and uptime.
In the CPU graph the colours yellow, cyan and green represent 'system', 'user' and 'nice' time, respectively, showing time spent
on system tasks, user-initiated tasks, and low-priority, background tasks. In the network graph the colours cyan and yellow
represent downloaded and uploaded traffic.
Now let's see what gkrellm says when we run on battery. With nothing much running, the frequency drops down to 600 MHz. In the table below we can see what happens with different kinds of load:
|With battery power but little load, the CPU usage is low and the frequency drops to 600 MHz to save power and heat.||With higher load, the CPU frequency automatically jumps up to 1 GHz to cope with the extra work.||The distributed.net client occupies the available CPU but doesn't demand a higher CPU frequency because it is 'nice' (shown in green).||When a movie player such as Xine is running, cpufreqd switches to full speed even if the CPU load is low.|
Now we have a means to check the effect of disabling cpufreqd. In the Mandrake Control Center (System - Configuration - Configure Your Computer) the services are listed under System - Enable or disable system services. Stopping the service cpufreqd stops the automatic changing of frequency, so it stays at its current value. By stopping the service at various frequencies, we can then check how the frequency (independent of other factors like CD spinning, hard drive access and so on) affects the battery life.
|Graphs of reported battery charge against time, running with different loads|
In this graph we show the discharge graph while running at its slowest, 600 MHz frequency, which looks as it did before, draining in a very
linear way in around 3.5 hours. We then show the same graph for 1000 MHz and 1600 MHz, which are again linear but drop significantly more
steeply even though the system load is just at idle. Finally, the steepest graph of all shows the processor at 1600 MHz but also additional
load on the system, including heavy processor use, intensive hard drive access, and dvd drive access. These power-hungry activities drain
the battery's energy in less than a third of the time taken by the power-saving mode.
We see, despite the confusing beginning, that indeed the frequency-stepping is working as desired, switching automatically based on
load and really saving power in a noticeable way. It also shows that 'background' tasks don't drive up the CPU frequency, and that
both CPU frequency and peripheral activity have a marked effect on battery life. Cpufreqd is doing its job properly, and can be
further configured by editing the file
/etc/cpufreqd.conf - see
man cpufreqd for more details.
As for charging, it would be nice to know how long it takes to charge, and whether the time taken depends on whether the laptop is running or not. It might make sense that it takes longer to charge when it's on, because the power's being used to drive the machine rather than charge the battery. On the other hand, it might just draw more current and still charge in the same time.
To test this, I plotted the reported percentage battery charge against time, for three cases. Firstly, with the machine switched on throughout the charge, secondly waiting half an hour before switching the machine on, and thirdly waiting an hour before switching on:
|Graphs of reported battery charge against time, during charging while on and off|
As you can see, it does make a small difference, but not as much as expected. Bottom line is, it charges in about an hour and a half, so if it can run for about 3 and a half hours when conserving power, that means it only needs to be plugged in for around 30% of the time.