Caffeinated Bitstream

Bits, bytes, and words.

HTC EVO and background network activity

HTC EVO, shown with the optional extended-life battery.

Earlier this year, I ditched my antiquated Treo 755p for the new hotness in mobile phones—the HTC EVO, an Android phone available from Sprint. Unlike my previous phone, which would last a full week in standby without recharging, the EVO gulps battery like there's no tomorrow. In fact, the limited battery life has been the primary complaint about the phone. Nobody seems to know for certain why the battery life is so poor. Maybe it's the beefy 1Ghz Snapdragon processor, the large LCD screen, or something else entirely.

I was recently traveling in a rural area, and noticed that my EVO's battery would only last halfway through the day. All mobile phones consume more battery in rural areas where they must transmit with greater power to stay in contact with faraway towers. However, the extent to which the EVO's battery life problems were exacerbated by the higher transmitting power got me thinking that perhaps at least some of the battery drain may be due to software which occasionally causes the radio to transmit.

All modern smartphones have various software components which periodically execute in the background, unbeknownst to the user, and sometimes activate the radio to chat with their buddies in the cloud. Some of this chatter may be useful for the user, such as having fresh mail delivered immediately, while other chatter may provide little or no value.

I got curious about what the phone's software was actually doing while I wasn't around, so I captured and analyzed all the network traffic from my phone over a period of four hours. I accomplished this by turning off the 3G radio and packet sniffing the Wi-Fi network. (I didn't have an easy means of sniffing the 3G traffic directly.) I have my phone syncing with my Google account, Google Latitude, a couple of mail servers, and Facebook, and this is reflected in the captured data. I did not touch the phone at all for the duration of the test, so this traffic represents only non-interactive use. Here are the main traffic categories, sorted by decreasing packet count, with local network maintenance traffic (ARP, DHCP, etc.) removed:

ip address host events packets bytes notes
209.8.115.0/24
66.220.0.0/16
profile.ak.fbcdn.net
api.facebook.com
21353921050 Facebook sync, including downloading profile photos of friends.
74.125.227.0/24mobilemaps.clients.google.com1127889604 Google Latitude updates
-mail_server_1723738572 IMAP/SSL mail traffic
-mail_server_2116787852 IMAP/SSL mail traffic
74.125.47.188yw-in-f188.1e100.netmany747298 Encrypted packets exchanged with Google throughout the period. This is probably the C2DM system which Google uses for push notifications.
-dns_server32649811 Various DNS names are queried throughout the period to support connections to the other services listed here.
184.73.171.111prod.sprintzone.org1326628 The Sprint Zone app periodically communicates with a Sprint server hosted on Amazon EC2 to receive information about promotions and announcements.
216.241.36.232static.ak.fbcdn.net
(via the local Akamai server)
2274728 Fetching the Facebook "no profile" image. (As part of the sync?)
208.17.80.85resources.static.mobitv.com1202296 Sprint TV service. This code seems to be sloppy—two identical HTTP transactions are launched at the same time.
98.137.133.176proxy101.mobile.vip.sp2.yahoo.com1153163 Yahoo Finance Widget: fetch latest stock prices
131.107.13.100time-nw.nist.gov18599 Query the date and time via the Daytime protocol. This server is located at Microsoft.
208.77.19.5us.pool.ntp.org12180 Query the date and time via NTP.

Lots of background network activity can be minimized by tweaking the sync settings.

In total, about 1.2 MB of data was exchanged in 2277 packets: 186 KB (1270 packets) were transmitted, and 1002 KB (1007 packets) were received.

The Facebook sync seems to be the biggest data hog of these background services. Every two hours, it is downloading information about all my Facebook contacts, as well as fetching profile pictures of most of them (whether or not the profile pictures have changed recently). The sync frequency for my "Facebook for HTC Sense" program can be changed in the settings, so I changed it from every two hours to once a day. After Facebook, the biggest consumers seem to be Latitude and my mail servers. I knew what I was getting into when I configured those, so I can't complain. I didn't even realize that I had Yahoo's "Stocks" program set to sync, so I turned that off altogether. The Sprint Zone sync frequency can be changed in the Sprint Zone application itself, although I haven't found a way to limit the Sprint TV syncing. The next time I'm traveling in a rural area, I should remember to turn off the "background data" and "auto-sync" items in the sync settings.

There are a few possible flaws in using this method to predict battery consumption. The exact relationship between network activity and energy usage is not clear to me. For example, is the transmitter only active for just long enough to send a packet, or does it remain on for a bit longer in the hopes of another packet becoming available in the send queue? What would consume more energy—a burst of 100 kilobytes, or 100 short transmissions of 1 kilobyte each, spread throughout a period of time? Is it more meaningful to consider packet counts, or the total byte count? Are some of these services only transmitting because they know the network connection is Wi-Fi and not 3G?