It seems like consumer networking companies are as determined to promote 2.4 GHz wireless products as the solution for in-home video streaming as Hollywood is to prevent its precious bits from escaping into the wild. But since DRM so far hasn't put much of a crimp into getting networkable video onto hard drives, it seems like all a geek needs to do is buy some gear and be watching wireless video in no time.
For some time, I've been critical of networking manufacturers' claims about 2.4 GHz wireless products as a solution for streaming video. Since the 2.4 GHz band is also used by microwave ovens, cordless phones and other products that don't speak Wi-Fi, the chances of interference are pretty good. And if non Wi-Fi devices aren't enough of a problem, just add in the problem of too many wireless LANs competing for too little bandwidth in too small an area. The result is that many folks who took the WLAN plunge can hardly get data tasks like web, email, chat and gaming to work reliably, let alone a high bit rate real-time application such as video to work.
But I have to admit that I haven't had any first-hand experience on how hard it is to get wireless video to work in high interference environments. So I set out to get some hard data that would really blow apart the vision of using the 2.4 GHz band for video streaming that manufacturers have been trying to get to dance in consumers' heads. What I found, however, is that manufacturers might not be as full of it as I had thought. But I get ahead of myself... Let's start by looking as why an overcrowded wireless band is not a good thing.
Overcrowded Spectrum Effects
If you're fortunate enough to have a clean 2.4 GHz spectrum, you only need to worry about whether your wireless gear can provide enough bandwidth at the locations where you want to watch streaming video. Fortunately, this is the problem that most of the industry has been focused on, i.e. throughput vs. range.
The latest step in the battle to extend the throughput vs. rate curve is 802.11n, the high speed extension to the 802.11 standards, which raises raw throughput claims to over 200 Mbps and in some cases closer to 300 Mbps. So even if you cut the claimed data rates in half to start getting closer to what WLAN products deliver in usable throughput, the resulting 100 Mbps or so should be plenty for wireless streaming, right?
But a large percentage of those who want to use WLAN gear don't have an uncluttered spectrum. Certainly apartment and dorm dwellers run the highest risk of WLAN disappointment. But even suburbanites in developments with homes that snuggle up closely to their neighbors' can also feel the no-clear-channel pain. And even if you don't have other wireless LANs in range, the abundance of 2.4 GHz spewing gear that most homes unknowingly have often cause would-be WLAN owners to give up and ship their purchase back from whence it came.
So the 2.4 GHz band used by 802.11b/g is too crowded for successful video streaming. But what does "too crowded" mean and how is it different from the problems caused by wireless gear that just doesn't have the required throughput at the desired range?
The three main effects of spectrum overcrowding are:
- Bandwidth Loss
Simply put, there are too many WLANs competing for too little spectrum. This causes not only a drop in available bandwidth, but usually also high bandwidth variation as neighboring WLANs compete for bandwidth.
- High Packet Loss
High RF noise levels from adjacent channel and non Wi-Fi interference sources (microwaves, cordless phones, etc.) cause bandwidth loss as lost or damaged packets are re-sent. In the worst case, non-correctable errors occur.
- Unreliable Connection
Wi-Fi users in crowded locations are very familiar with the problem of the client that keeps trying to connect to a neighbor's WLAN. This is usually due to the neighboring WLAN's access point (AP) or wireless router transmitting a stronger signal than your own AP. This coupled with the promiscuous default settings of Windows' built-in wireless utility usually results in a client that won't stay put.
It's obvious that if you run out of bandwidth or keep dropping a connection that any application won't work. But how much packet loss can streaming video withstand before it disturbs your viewing pleasure?
As luck would have it, Apposite Technologies was kind enough to loan a Linktropy 4500 WAN Emulator (Figure 1) to help me answer this question. The 4500 is a hardware-based emulator that allows adjustment of upstream and downstream bandwidth, delay and loss. It has a web GUI that can be accessed via a dedicated Ethernet management port, or by in-band clients. If command line interfaces are more to your taste, there's also a serial console port where you can plug in and have at it.
Figure 1: Apposite Technologies Linktropy 4500 WAN Emulator
The 4500 is simply connected between any two Ethernet LAN segments via its 10/100/1000 LAN A and B ports. By default, it acts as a transparent learning bridge so will work with any protocol. It can also be switched into routing mode for IP frames only, and can't be used for multicast applications while routing.
Once connected, the desired network characteristics are entered into the management interface (Figure 2). Emulation can be turned on and off without having to change any of the settings by simply clicking on the virtual Emulation On/Off switch in the management interface screen.
As mentioned previously, you can control bandwidth, delay and loss for traffic passing in both directions through the 4500. The delay parameter is the only one that can vary with either a normal or uniform statistical distribution in addition to the static setting. I would have liked to see at least the loss and perhaps the bandwidth settings also be similarly variable, since that would have more accurately emulated a wireless connection. But I was able to get a good feel for loss effects with just the static setting.
Figure 2: Link Emulation screen
The 4500 can also display statistics in both directions (but only when emulation is enabled) along with a running plot of transmission rate (Figure 3).
Figure 3: Link Statistics screen
Setup consisted simply of connecting the 4500's LAN A port to one of my LAN switch's ports and its LAN B port to one of my computers. My learning curve with the 4500 was virtually nil and I was able to crap up my network performance in various ways in virtually no time. The longest thing that it took me to learn was finding the software switch that allowed me to change from using the dedicated Ethernet Management port over to accessing the web GUI via a computer connected to a LAN segment that was connected to the 4500.