Monthly Archives: January 2015

A better way of collecting usage stats in mobile applications

Let me start by setting some context. As a part of my course requirements, I have performed a study on TCP connections of various mobile applications. An interesting phenomenon that caught my attention is the various usage measurement stats being collected by application publishers. Many apps were sending information about the application usage to remote servers periodically. In a research paper titled, “Profiling Resource Usage for Mobile Applications: A Cross-layer Approach”, I learnt that during the time that the handset takes to turn off the radio (IDLE state) after it detects silence for a threshold (this is called tail period) consumes equal amount of energy as to when the communication is active. Now, I see a problem with these usage stats collection services.

Services like, Splunk MINT, Flurry,, Localytics etc help app developers gain insights on how their app is being used. While it is a great idea to use these stats to optimize user experience, periodically sending out data can be bad to battery usage on your smartphones. Here is why –

Let’s consider a device has a tail time of around 5 seconds (most devices have a tail time of 12 seconds). Meaning, the device waits for 5 seconds before turning off the radio after it observes a silence period. Now, let’s consider an app which uses a measurement tracking service that collects user stats every 8 sec or whenever a user performs an action (say for example, a click).

Case 1: Let’s say the user didn’t click anything for 10 seconds. Now the stats collection service will send the stats report in a burst of data to the server after 8 seconds. So, the radio that was turned off after the 5th second, now got activated again due to the burst of data packets. A significant amount of power is wasted during the tail time + the power needed to re-activate the radio.

Dead Battery

Case 2: Let’s consider the case that the user performed a click on the app (a region where clicking doesn’t cause anything to happen on the front end, may be to ensure the screen doesn’t dim off) at the 4th second, the stats collection service sends the data to the servers which means again a burst of data and the count down of 5 seconds is stopped. The radio will not be turned off until 5 seconds after the data transfer to the stats collection server is complete. Meaning, the power consumption isn’t reduced even though there is apparently no change on the front-end.

Case 3: Let’s consider the scenario where despite of any action on the user’s end, the stats collection service send the metrics to the server every 4 seconds. This keeps the radio in transmission state through out the time the app is open. If this app is a gaming app, which you like and you play for a couple of hours every day, the battery is drained super fast not because of the game itself, but the background usage measurement collection service.

Here is what I think is a good way to collect stats while not draining the battery.

These services can collect the stats in the following ways –

1. If the app doesn’t get any data from the internet, say a static game application, collect the stats through out the time the app is open and then send all the collected data at once in a single burst when the user closes the app. Now, there is a chance that the app crashes and the close doesn’t happen in a proper way. In those cases, the app has to check for data collected but not transmitted upon re-opening and then send them right away. In this method, may be the stats are not real-time, but the developer can still get insights while not hurting the resource utilization on the handset.

2. If the app is, say, a music service, it periodically downloads some information like songs or playlist information etc from its server. The stats collection mechanism can use this window to relay the collected stats until that time from previous send. This way, the radio time used by the stats service will be during the radio time used by the actual app thereby not effecting the battery much. This is partially real-time depending upon the intervals in which the app uses the transmission radio.

The same mechanism can be used to ad networks that reload the ads after a certain period of time (say 120 sec). The ad-network module of the app can pre-load certain ads to rotate during the app open time when the app loads for the first time. Or it can also use the radio window of the original app to fetch new set of ads depending upon the need).

This is just my idea and I may be wrong. Comments are welcome.


Feng Qian , Zhaoguang Wang , Alexandre Gerber , Zhuoqing Mao , Subhabrata Sen , Oliver Spatscheck, Profiling resource usage for mobile applications: a cross-layer approach, Proceedings of the 9th international conference on Mobile systems, applications, and services, June 28-July 01, 2011, Bethesda, Maryland, USA

How to setup OpenVPN Client on DD-WRT with is one of the most affordable and reliable VPN services out in the world of VPNs. Plans start at about £1/year, that’s dirt cheap. Now, most of us wants to be connected to the Internet via a VPN for various reasons. However, in today’s connected world, each person owns about 2-3 devices on average that always stay connected to the Internet in which case, you will have to setup a VPN client on each one of those and handle connections individually. It is ofcourse a pain in the ass. Hence the only solution is to connect the router itself to the VPN so that all the devices behind the router are sending out and receiving the traffic via the VPN automatically. This tutorial helps people looking forward to setup their DD-WRT router to connect to service.

Why Why not my own OpenVPN on a VPS?

I have been playing around with OpenVPN on Low End VPS boxes for quite some time. So, I know what I’m saying. Here are the reasons why I prefer to my own setup of OpenVPN –

I frequently experiment with my VPS. So, more scope for service disruption. Although I can rebuild the complete VPN service in under 5 min, the sheer number of times I experiment and fail, thereby resulting in unavailability of VPN service leads to the feeling that I should obtain VPN services from a provider for a cost.

Having VPS boxes in multiple locations is going to be expensive. Because it is only you who use your service (or may be some family – who expects money from family for providing a no guarantee service?) paying for those boxes across various locations on the globe is very expensive. And as there are numerous customers like you using services like, it is fairly profitable for them to procure new locations.

A single Low End VPS would cost about $2/year on the minimum side. When a service provider like offers a fairly good deal for £1/year ($1.52/year), with guarantee of reliability and multiple locations, I would definitely go for it.

Now, the downside to this is that, the bandwidth is fairly limited. gives you about 150-250GB for this plan, while you may get upto a TB of bandwidth on a VPS for $2/year. But, who cares when all you need is to connect via a VPS to do some browsing stuff or make VoIP calls?


You are here, means that you know what you are upto. Hence, I don’t think I need to explain you the powerful features of DD-WRT. For the sake of this tutorial, let me say that it has got a OpenVPN client built in and it is fairly easy to connect to the VPN at router level.

A quick guide on how to setup DD-WRT on your router can be found here.

Setting up OpenVPN Client on DD-WRT

Now is the time to set that VPN connection on your router.

  1. Log in to the administrative interface of DD-WRT (usually; Default Username: root; Default Password: admin)
  2. Setup your internet connection normally as you would on a router
  3. Go to Administration -> Commands
  4. Modify this script as mentioned in-line
  5. Paste the modified script into the Command textarea
  6. Save it as a Startup Script
  7. Reboot the router

This script is run at the time of router booting and a VPN connection is established with Let me know if you have any troubles.