First Time Linux

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.

cpuinfo

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

Throttling

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.

cpufreqd

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 cpuinfo file, and again no difference to the battery life, whether this daemon is running or not.

gkrellm

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.

Conclusion

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.

Battery charging

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.