Powermanagement - HTC Dream aka G1

One of the biggest issues in mobile devices today is power management. On the one hand we expect that the device is always responsive, to user input and network events, on the other hand we want all subsystems to be powered (almost) off to save power.

[ update on G1, it is not as shiny as I thought, see buttom... ]

On an average mobile lithium polymer battery at about 1300mAh even small additional current drains result in significant standby time losses - calculate 2mA standby current -> 650h -> 27 days, 4mA -> 13.5 days, 6mA -> 9 days, 8mA -> 6.7 days. And now take into account that just a regular LED already takes 20mA (or ~10mA with a good regulator). So *every* mA you can save is precious and reaching the area of 4mA to 6mA is already in the range of the current needed to self refresh the SDRAM plus some leakage and regulator overhead, not even talking about thins like a GSM modem.

In most mobile designs today you will therefor find a "deep sleep" approach, i.e. to save power the CPU powers down all peripherals, puts the SDRAM into self-refresh and finally itself to sleep, usually loosing all its state (true for PXA, S3C, MPC, etc.). Some CPUs support a static state where at least the CPU internal state is kept while in deep sleep which helps implementing the wakeup path.

But this approach has a big disadvantage. The latency for waking up again is pretty high, periherals need to be reinitialised and the CPU state needs to be restored.

Now think of ordinary mobile phones like you know them from Nokia, even their higher end smartphones. Those devices do not expose a deliberate standby mode, they seem to be running all the time, they even update data on their displays, like missed incoming calls, a clock, etc.

How do they do that?

They use a different approach which is pretty hard to implement but extraordinarily useful! They do not power off peripherals but put them into a very low power state which keeps their state and can even keep them being responsive (like WiFi still being able to receive packets). This requires a *very* careful hardware choice and a very finegrain control of the software so it does not trigger CPU activity too often. The CPU in this case is not sent to sleep and the RAM is kept running too. But all clocks are reduced to an absolute minimum, just enough to keep the system alive. If an external event occurs they can now quickly wake up, process the event and go to sleep again.

In the mobile Linux realm so far the only device I knew of that used this approach were the Nokia tablets, 770, N800 and N810. Those devices are able to keep online and connected for *days* on a single battery. Impossible for most (or all?) PXA or S3C devices. And even if the wakeup from normal sleep is pretty fast, around one to two seconds, but still ages compared to instantly available on devices that just slow down.

I just found out that we now know a new one that can do exactly that: The HTC Dream, aka T-mobile G1!

Following is a very conclusive "ping" log:

64 bytes from 192.168.2.163: icmp_seq=93 ttl=64 time=52.2 ms
64 bytes from 192.168.2.163: icmp_seq=94 ttl=64 time=77.0 ms
64 bytes from 192.168.2.163: icmp_seq=95 ttl=64 time=106 ms
64 bytes from 192.168.2.163: icmp_seq=96 ttl=64 time=126 ms
64 bytes from 192.168.2.163: icmp_seq=97 ttl=64 time=45.4 ms
64 bytes from 192.168.2.163: icmp_seq=98 ttl=64 time=62.3 ms
64 bytes from 192.168.2.163: icmp_seq=99 ttl=64 time=85.3 ms
64 bytes from 192.168.2.163: icmp_seq=100 ttl=64 time=114 ms
64 bytes from 192.168.2.163: icmp_seq=101 ttl=64 time=35.4 ms
64 bytes from 192.168.2.163: icmp_seq=102 ttl=64 time=49.5 ms
64 bytes from 192.168.2.163: icmp_seq=103 ttl=64 time=74.8 ms
64 bytes from 192.168.2.163: icmp_seq=104 ttl=64 time=101 ms
64 bytes from 192.168.2.163: icmp_seq=105 ttl=64 time=117 ms
64 bytes from 192.168.2.163: icmp_seq=106 ttl=64 time=44.4 ms
64 bytes from 192.168.2.163: icmp_seq=107 ttl=64 time=62.3 ms
64 bytes from 192.168.2.163: icmp_seq=108 ttl=64 time=75.5 ms
64 bytes from 192.168.2.163: icmp_seq=109 ttl=64 time=305 ms
64 bytes from 192.168.2.163: icmp_seq=110 ttl=64 time=208 ms
64 bytes from 192.168.2.163: icmp_seq=111 ttl=64 time=236 ms
64 bytes from 192.168.2.163: icmp_seq=112 ttl=64 time=257 ms
64 bytes from 192.168.2.163: icmp_seq=113 ttl=64 time=279 ms
64 bytes from 192.168.2.163: icmp_seq=114 ttl=64 time=303 ms
64 bytes from 192.168.2.163: icmp_seq=115 ttl=64 time=226 ms
64 bytes from 192.168.2.163: icmp_seq=116 ttl=64 time=243 ms
64 bytes from 192.168.2.163: icmp_seq=117 ttl=64 time=271 ms
64 bytes from 192.168.2.163: icmp_seq=118 ttl=64 time=305 ms
64 bytes from 192.168.2.163: icmp_seq=119 ttl=64 time=214 ms
64 bytes from 192.168.2.163: icmp_seq=120 ttl=64 time=233 ms
64 bytes from 192.168.2.163: icmp_seq=121 ttl=64 time=258 ms
64 bytes from 192.168.2.163: icmp_seq=122 ttl=64 time=279 ms
64 bytes from 192.168.2.163: icmp_seq=123 ttl=64 time=302 ms
64 bytes from 192.168.2.163: icmp_seq=124 ttl=64 time=221 ms
64 bytes from 192.168.2.163: icmp_seq=125 ttl=64 time=250 ms
64 bytes from 192.168.2.163: icmp_seq=126 ttl=64 time=273 ms
64 bytes from 192.168.2.163: icmp_seq=127 ttl=64 time=296 ms
64 bytes from 192.168.2.163: icmp_seq=128 ttl=64 time=211 ms
64 bytes from 192.168.2.163: icmp_seq=129 ttl=64 time=54.5 ms
64 bytes from 192.168.2.163: icmp_seq=130 ttl=64 time=76.3 ms

What you can see here is that at runtime (display on etc.) the ping times are around 50ms to 80ms. Then I pressed the power button and the device "went to sleep", at least it looked like it. Actually it does not completely sleep, the WiFi is still pingable which means that the WiFi module is still up and running and that the IP stack of the Linux kernel is up and running which in turn means that the CPU is alive. The latency is higher since the CPU will be put into some kind of hot-standby and takes additional time to either get up to speed again or it stays in a low clocked mode and it simply takes it longer to process the ping response.

So, why is that this important?
Well, imagine applications like a VOIP telephony application and an incoming call. You definitely want to have your phone in some kind of low power or standby state if you are not actually using it. But it must still be able to respond to an incoming call request.
So here you are - works!

At the moment with the Android 1.5 system it still switches back to cellular data in standby if the WiFi is idle but if you keep pinging it it stays conectable all the time.

This is pretty good news for me. Next I will have to dig out the Linux kernel source for the G1 and see if it is complete. If it is then the G1 is IMHO the most perfect Linux phone hardware an open source developer can currently think of. If it lacks parts I will have to bash T-mobile for releasing them - I am a normal customer and according to GPL (kernel is GPL) I have the right to get the sources!

Update:

It seems that both assumptions are not fully true on the G1. The device is still pingable for a significant amount of time but on the other hand there are suspend and resume kernel messages in dmesg.

So what this tell us?
They still do normal suspend/resume. Definitely.
But they hide quite cleverly, as it seems. The device seems to really immediately resume, it seems to be responsive even in sleep but still it suspends at some point. Not bad.
This is the point where one would have to write a test application to verify how it works. Wolunteers?