Wireless Wanders header image 1
Wireless Wanders header image 2

The ongoing pain of the mobile data ‘experience’…

February 28th, 2008 · 1 Comment

I’ve been using mobile data services since their inception. I remember ‘back in the day’ using circuit switched GSM data calls with my Toshiba Libretto, painfully waiting for anything to happen at all, never mind for a page to load. Remember all that nonsense about Com 11, Com 9 and every other Com but the one you needed?

Now, we have EDGE and 3G and all these other ‘fast’ networks. However, the simple fact remains that what matters is true end-to-end performance, not network speed. It’s basic engineering stuff, known as a delay budget. To get a web page on my mobile, a number of software processes and protocol exchanges have to take place. Once we understand this, it might help us to understand problems like the one I picked up on the O2 iPhone forum:

My brother got a Three phone with 3g and we tried opening a bbc site on his phone and on my iphone .. my iphone loads the bbc.co.uk in 8 sec which is fully loaded with images and everything.. and on his 3g phone first of all s**t browser, s**t speed took 35 sec to load only half of the page…

This type of problem is not uncommon. I have demonstrated it many times to unsuspecting student mobilists. I don’t know the details of ‘my brother’ above. Perhaps he didn’t have a 3G connection at all and didn’t notice that he was roaming onto O2’s GPRS network instead. Perhaps he was in a location with poor 3G connectivity. Even with great signal strength, the data rate could still be poor, for a number of reasons: network capacity, poor uplink performance etc.

Whatever the reason, the user here is under the impression that 3UK’s 3G network is slow, whereas that might not be the case at all. The radio part of the network might be fast. Here’s where the delay budget can come in to the picture. Firstly, the handset itself might allocate a low amount of processing power and priority to the page rendering. This is a very common architectural deficiency on many phones. There are so many ways to implement the browser and HTTP stack that are incredibly inefficient. Hence, the network does a great job of squirting bits of data down the pipe, but the phone itself does a poor job of requesting the data chunks and then rendering them to the screen.

On the other hand, the core network might be the source of the problem. This is often the case. A simple demonstration of this is loading an iPhone app with WiFi on and then off. Typically the WiFi link will load the apps in a matter of seconds. On the iPhone, at least on the O2 network, you can wait a long time to get the same page. I’ve measure it a number of times. I just tried the same page now (with no graphics) and waited 6 seconds on WiFi and then 50 seconds on GPRS, most of which was the browser waiting for the page. Please, someone fix this!

Technorati Tags: , , , , ,

Tags: Wireless

1 response so far ↓

  • 1 David // Feb 28, 2008 at 10:50 am

    When I first got T-Mobile web’n'walk I quickly found that a very good tip was to change the DNS server setting to something other than T-Mobile’s DNS. It seemed quite amazing to me that they would build out a network and then fluff the DNS server so that it was quicker to transport the lookup *outside* of their network than resolve it inside. Since the DNS lookup is right at the beginning of any web transaction this fed straight through to their page latency. It also amazes me that given this public information about their deficiencies (already debugged, not just whining) that the problems don’t get fixed more quickly.

Leave a Comment