Making TinyPlazer more Tiny

I set up a few months ago as a mobile-device-friendly way to update my Plazes geo-presence. I targetted it for my Nokia N95 and because I use it without a data plan in Canada, its “tinyness” assumed a wifi connection. In other words, I wanted it to be lightweight, but I wasn’t counting the bytes.

Here in Copenhagen I do have a data plan on my mobile: it costs me 0,02 DKK per kilobyte of data transfer (this is 0.004 CAD, which makes Canadian Rogers Wireless pre-paid data 12.5 times more expensive than Danish Telia pre-paid data).

So today I used for the first time over an actual GSM data connection. The process of identifying and confirming my Plaze, entering my status message, and receiving a confirmation cost me 0,30 DKK. Or about 6 cents CAD.

Which is certainly reasonable, and about 1/3 the price of updating my presence by SMS (0,20 DKK).

But, I ask myself, could it be even less?

The Web Developer add-on for Firefox told me the weight of all of the objects on the initial page was 3KB: 1KB for the HTML itself, 1KB for the logo and 810 bytes for the CSS.

I was able to reduce the size of the CSS file from 810 bytes to 321 bytes just by removing styles I wasn’t actually using, consolidating some styles together, and removing whitespace. Similarly, I chopped 200 bytes out of the page itself by shortening class names, removing whitespace, and making better use of CSS, taking it from 1070 bytes to 848 bytes. I changed the logo from one big graphic to a small Plazes logo following by text, reducing the weight to 593 bytes.

The result was a total reduction in page weight to 1762 bytes.

The second “select your Plaze” has a varying weight depending on the number of Plazes returned. Because experience has shown I almost always pick from the top 5 displayed, even though I display 10, I reduced this to 5 selections.

Testing my changes with an actual GSM “plazing.” I found the combined effect of all of these changes lowered the per-Plazing cost by GSM data from 0,30 DKK to 0,22 DKK, or by about 25%.

This charge suggests a total data transfer of 11KB. My N95’s log (Applications \| Tools \| Log) shows 5KB sent and 5KB received:

Nokia N95 pack data counter log screen shot

Presumably Telia is doing some “round up to the nearest KB” to get the 11KB data charge.

Looking at the Apache server logs for this session, I see a record of five transactions, four GETs and one POST. Total data transfered: 3272 bytes. But this doesn’t count the HTTP send and response headers.

Looking at a sample HTTP transaction in more detail, the request for the CSS file, using cURL’s “trace” option, I find that the request for the 321 bytes of the file itself involves 242 bytes of send headers and 283 bytes of response headers, meaning that 321 bytes actually takes 846 bytes to transfer.

I traced the total data transfer for each of the five transactions:

Transaction Send
Index Page 241 233 848 1322
CSS 242 283 321 846
Logo 240 284 593 1117
POST form 355 231 739 1325
Confirmation 287 231 771 1289
TOTAL 1365 1262 3272 5899

So for what I’m able to count, I get a total sent data of 1365 bytes (vs. my phone’s 5KB counter) and a total received data of 4534 bytes (again, vs. 5KB counted by my phone), for a total of 6899 bytes. Which is not 11KB.

To try and see if there’s some sort of uncountable overhead involved with GSM data, I used Profimail to pick up my IMAP email over a GSM connection, and reset its data counters before I did. Profimail counted a total of 0.3KB sent and 5.69KB received, for a total of 5.99KB. My phone’s own log, however, shows 1KB sent and 8KB received, for a total of 9KB, which is 3KB more than Profimail reports. Telia billed me 0,20 DKK for this session, or 10KB.

This suggests that the data counting is happening at some deeper level, beyond my ability to measure, and perhaps involving the overhead of using TCP/IP over GSM. This “premium” appears to be about 50% of the data transfer that I can calculate, so that:

Measurable HTTP transfer x 1.5 = Billed Data Tranfer

I’d welcome any insight others might have into this issue, and any suggestions you might have for reducing either the measurable or the “invisible” data transfer payload.


Peter Rukavina's picture
Peter Rukavina on June 19, 2008 - 20:20 Permalink

Some follow-up: I believe that because I’m using a North American N95 8GB, I’m not using 3G, but rather old-school GPRS data (forgive me if I’m using terminology incorrectly). This post on an AT&T message board sheds a little light on what might be called “billable overhead.”

Peter Rukavina's picture
Peter Rukavina on June 19, 2008 - 20:41 Permalink

Final followup: Protocol Overhead in GPRS from Ericsson goes into the issue in considerable detail.

It seems, in the end, that while I might assume I’m paying to transfer the actual data that I can hold in my hands, I’m actually paying for the amount of data it takes a mobile phone to communicate over GPRS.

oliver's picture
oliver on June 20, 2008 - 02:41 Permalink

You’ve made your cargo so light that your bill is just the weight of the packaging? Another possibility seems like you’re just over the fundamental packet size and getting billed for two packets, although one is mostly empty. That “Protocol Overhead” article seems to imply this liability when it talks about ideal packet sizes and about overhead depending on how much you’re sending and from what OS. You might do an experiment in which you send a series of incrementally larger cargoes and graph what weight your company tallies them to be. It will rise step-wise rather than as a slope if you’re fighting against the fundamental packet size. Also I wonder if you know how long a return address and header content your phone and provider are attaching to your packets and whether some are less overkill than others. (Maybe a really primitive network geared to communicating between devices with no bells and whistles would use a smaller header? What do/did pagers use?).

oliver's picture
oliver on June 20, 2008 - 02:44 Permalink

i.e. “whether THE HEADERS OF some PHONEs AND/OR PROVIDERs are less overkill than others.”

oliver's picture
oliver on June 20, 2008 - 02:54 Permalink

Could you have users cache/install a copy of the logo and other standard content on their phones? Or will phone browsers not fetch from their own memory? (I’m probably in way over my head here)

Steven Garrity's picture
Steven Garrity on June 22, 2008 - 15:20 Permalink

Using The Gimp, I managed to get the logo PNG image down from 593 to 330 bytes by reducing the color palette and cleaning up some of the dithering. The changes shouldn’t really be noticable. Here’s the optimized version:…

You own be $0.02.

Peter Rukavina's picture
Peter Rukavina on June 22, 2008 - 17:36 Permalink

Your $0.02, which PayPal somehow converts to $0.03, is on the way as we speak. Spend it wisely.

Steven Garrity's picture
Steven Garrity on June 22, 2008 - 17:53 Permalink

From the PayPal receipt:

Total Amount: $0.02 CAD
Fee Amount: -$0.02 CAD
Net Amount: $0.00 CAD

It seems I have already spent it wisely.

Peter Rukavina's picture
Peter Rukavina on June 22, 2008 - 18:51 Permalink

Maybe this is how PayPal makes money. I wonder if the fee for a 10 cent payment is 10 cents too?