Scaling to 802.11ac Speeds in Smartphones and Tablets
by Anand Lal Shimpi on January 5, 2012 8:00 AM EST- Posted in
- Smartphones
- Mobile
- 802.11ac
- HSIC
- Tablets
I promise this is the last thing I'll write about 802.11ac today, but it is very relevant to our smartphone and tablet coverage. If you've followed any of our reviews in the mobile space you'll notice that there seems to be a bit of a glass ceiling in terms of WiFi performance on smartphones and tablets:
We have yet to see a device that can download consistently at more than 36Mbps. For most smartphones/tablets this isn't alarming as they only support 2.4GHz 802.11n and a single spatial stream, resulting in a maximum interface speed of 72Mbps. Factor in loss and overhead and you're left with about half that as real world performance.
It turns out, as you'd expect, that there's another bottleneck in these devices limiting their peak WiFi performance: the SDIO interface and it's associated drivers.
SDIO is an I/O interface based on the Secure Digital (SD) standard. This is the same standard that is used for removable flash storage in cameras. The SDIO interface itself is capable of a maximum bandwidth of 100Mbps. It turns out that the SDIO software stack can further limit the interface's performance to the 30 - 40Mbps range. The appeal of rewriting SDIO drivers for Android likely contributes to continued propagation of this issue.
One solution to this problem is a transition to a more modern interface: HSIC. HSIC (High-Speed Inter-Chip) is a serial USB based interface that is destined to replace SDIO. Whereas today SDIO based WiFi solutions are offered to phone and tablet vendors, with 802.11ac we'll see both SDIO and HSIC versions. HSIC should guarantee speeds of up to 480Mbps (theoretical).
The HSIC software stack is also apparently more robust and isn't expected to pose a problem in the way that SDIO has thus far. Given that smartphones and tablets are expected to use single stream 802.11ac at 433Mbps, HSIC looks to be the appropriate SoC interface.
It remains to be seen how fast 802.11ac will be in practice. But if all goes well, I wouldn't be too surprised to see at least 100Mbps over 802.11ac WiFi on a smartphone in the next two years. If we're lucky, we may even get 2 - 3x that.
Facebook
Twitter
RSS
15 Comments
View All Comments
therealnickdanger - Thursday, January 5, 2012 - link
HSIC sounds like a great step forward and is likely going to require better performing storage. Just as modern SSDs have improved general computing for desktops and notebooks, it would be great to see some of that great random read/write performance trickle down to the SD card market. The best Class10 SD card might be able to push 22MB/sec sequential, but they're still abysmal in random performance. I notice hangs and delays all the time when doing lots of simultaneous operations on my Android phones, delays which could be greatly reduced or eliminated with some better storage (internal and external).Tanclearas - Thursday, January 5, 2012 - link
This comment could pretty much go in any number of Anandtech articles that touch on "network speeds". This includes WiFi articles, but also most smartphone articles that discuss 4G/3G/3.5G.Bandwidth isn't the problem. The real problem is ridiculously large web pages. Anandtech is well over 1MB for the home page alone.
If you want to "improve" network speeds, do your part.
name99 - Thursday, January 5, 2012 - link
Uhh. Just so you know, people use networks for more than just browsing web pages...Meanwhile, if the size of the AnandTech page continues to offend you, use this alternative:
http://www.google.com/gwt/n?u=http%3A%2F%2Fwww.ana...
Tanclearas - Monday, January 9, 2012 - link
Indeed. However, using tablets and smartphones, it is unlikely that you are transfering huge files. At 36Mbps, or even at mere 3G speeds, I have no issues at all watching streaming videos, or other network-related tasks typical of a tablet or smartphone.Anandtech isn't the only site that is bloated, and using the web shouldn't be an exercise in figuring out how to load a site by alternative means.
B3an - Friday, January 6, 2012 - link
1MB+ for a site like this is more than acceptable with todays speeds. Especially with all the images, which are pretty much need being as people like to SEE what is being reviewed. To get it under 1MB the compression on the image would have to be so bad that the site would look like total shit.Go back to the 90's and reading plain text. Or just grow some fucking brain cells.
GoodGrief - Friday, January 6, 2012 - link
That's the mindset that gets us the crap bloatware we see so often today. It's why we have multi-gigabyte <word processor applications>. It doesn't matter how fat your pipe is, a smaller piece of data will transfer quicker than a bigger one on the same pipe - ALWAYS. We can store more content with less space, send files faster, and perform more simultaneous transactions - without requiring more hardware. Responsible use of data is a win for everyone.So, let's talk about this specific article then. Not counting the site headers, and other shared assets, there's only two unique images.
- One is a completely useless graphic that's a visual representation of the article headline. That one is for idiots like you who NEED a shiny, but pointless picture to stare at. It provides ZERO information, but it's 217 KB of data. The bandwidth spent loading that could've been used on something <useful>, but hey, they gotta' pander to the mouth-breathers that need shiny-but-useless pictures. :/
- Even better is the second graphic. It's the graph. It's 44 KB of data. I can (and did) recreate that exact same graph image with some basic HTML, CSS, and a single SVG image - AND DO IT ALL in less than 8 KB of data (and I wasn't being terribly bit-conscious). That's a minimum of 36 KB of absolutely unnecessary data & wasted bandwidth - it won't even change the viewable content of the page. Not only that, the code is reusable, and they could template all their graphs with a tiny addition to what I did and save massive amounts of storage space and bandwidth that could be used on something else - and lose <nothing> in the process. Not only that, the graph "images" could be trivially indexed and searched by content, since the meaningful data would be entirely plaintext.
So, before you nit-witted, mouth-breathing morons go firing off your mouths (figuratively speaking) in response to a perfectly legitimate call to make something more efficient, perhaps YOU should "grow some fucking braincells".
Tanclearas - Monday, January 9, 2012 - link
Perhaps you should try leaving your house or city and travel around a little bit and realize that there are huge sections of the continent where you will end up on 2G networks. You're right. This isn't the 90's, but sadly you're are blissfully oblivious to the fact that high-speed networks are not available anywhere you want them to be.Perhaps you should go back to school for more practice reading text to remove your dependency on graphics.
Perhaps you could even learn a little about web design and graphics and realize that getting the Anandtech page under 1MB wouldn't really be that hard at all (see the great post by GoodGrief). In addition to his comments, I would add that the Facebook Social plugin is a wonderfully useless chunk of data for the page. Also, how important is it really to see product shots for nearly every article summary?
alpha64 - Thursday, January 5, 2012 - link
Even in 5GHz, most mobile devices only support 20MHz channels with a single stream, resulting in 72Mbit PHY speed, thus causing the speed ceiling. This is due to the fact that 40MHz and multiple streams each suck significant battery power.This is my understanding for the speed ceiling.
Anand Lal Shimpi - Thursday, January 5, 2012 - link
Very good point :) I've adjusted the text a bit to not mislead there :)Take care,
Anand
alevmak - Wednesday, January 11, 2012 - link
My understanding was that you get 150Mbit per spatial stream using the 20MHz channel, and 300Mbit at 150Mbit per spatial stream using the 40MHz channel.