Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Introduction

In Part 1, I was surprised at how little packet loss it took to affect video streaming, but was just as surprised at how hard it was to disturb files played using TCP/IP based protocols. Armed with this knowledge, I set out to see whether success in wireless video streaming was really as hard as I have been making it out to be.

We found in Part 1 that video streams can vary widely in their bandwidth needs and that there are two methods for playing video files across a network. Since I mainly wanted to explore the largest uncontrollable factor in wireless streaming - neighboring WLANs - I decided to use one test file and one play method. I chose an uncompressed VOB (MPEG2) test file with a bandwidth profile shown in Figure 1. The bandwidth was measured using Hoo Technologies' Net Meter.

Test file bandwidth profile

Figure 1: Test file bandwidth profile

The four-minute test file has plenty of action in it, which accounts for the fairly high average bandwidth. These figures are above the 5 Mbps or so bandwidth number that I've heard thrown around in IPTV-related discussions with equipment vendors, but aren't out of the question for downloaded or ripped content. For comparison, Figure 2 shows the bandwidth profile of a short HD movie trailer.

Quicktime HD 720p file bandwidth profile

Figure 2: Quicktime HD 720p file bandwidth profile

Note that this is a 720p file in Quicktime HD, which uses the very bandwidth-efficient H.264 codec. While the average bandwidth (the one that most vendors will quote, of course) of the HD file is lower than the test file's, the peaks are more than 3 times higher.

I chose UDP streaming as the play method because it is the most likely to be used by both network-based content providers and for in-home network play of downloaded and stored content by devices using UPnP AV and DLNA protocols.

Test Setup

I started out with a simple test two-WLAN setup, figuring that I could always make it more complicated if I needed to (Figure 3). I used two Linksys WRT54G routers configured as access points (see this link for a quick how-to). Using them as access points ensured that I wouldn't encounter any of the routing problems that the v5 router has. Plus, the lack of NAT firewalls made it easy for the IxChariot console to control everything.

Figure 3: Test setup configuration

Figure 3: Test setup configuration

I mixed things up a bit on the client side because I didn't have two WPC54G notebook cards. So the "Neighbor" client used the Gigabyte GN-WPEAG mini-PCI card that I had added to my Fujitsu S2020 Lifebook awhile back. The Gigabyte card uses an Atheros Super-G chipset, which had no problem working with the Broadcom-based radios in the Linksys routers. The "Home" client is my trusty Dell 4100 Inspiron with 1GHz Celeron and 576MB of RAM, running Windows XP Home SP2.

To simulate the worst case of two WLANs on the same channel, both routers were set to Channel 6. I left all the other settings at their defaults (Figure 4) and no encryption was used.

Test Setup

Figure 4: Wireless settings for Linksys WRT54G's

To put a little distance between me and my potentially interfering WLAN, I set up the "Neighbor" WLAN as shown in Figure 5. The walls are 2x4 sheetrock with no ducting or metallized insulation in them. This setup attenuated the "Neighbor" WLAN's signal somewhat, but the "Home" client still reported an "excellent" signal when I temporarily connected it to the "Neighbor" WLAN AP.

Figure 5: Test area floor plan

Figure 5: Test area floor plan

Bandwidth Requirements

It may be obvious - however judging from some of the mail I get on the subject it may not be - but the key rule for successful wireless streaming is:

The available bandwidth of the connection must be sufficient to support the bandwidth required by the content.

Figures 6 and 7 illustrate the rule, showing IxChariot plots of a single wireless connection between the "Home" WRT54G and WPC54G client card. Figure 6 starts out with an IxChariot throughput.scr script running TCP with a file size of 100,000 Bytes. You can think of this as simulating a long file download. After about 45 seconds, I started streaming the test video over the same connection to the same client.

Shared data and video stream - 11g WLAN

Figure 6: Shared data and video stream - 11g WLAN

While it's not a one-to-one match, if you take the bandwidth profile of the test file in Figure 1 and flip it upside down, it corresponds reasonably well to the "bite" taken out of what would otherwise be a straight 21 Mbps throughput line. Another check is that the throughput drops by about 9 Mbps - the average throughput of our test video file.

What was surprising here is that the video stream takes all the bandwidth it needs, dropping the speed of the IxChariot throughput script, i.e. our file download. This happened with the Wireless Quality of Service (QoS) / WMM mechanism in both routers disabled and with no sign or QoS or WMM in the client card properties or settings. So it appears that the available bandwidth for streaming in this particular WLAN is the total bandwidth. This polite behavior isn't guaranteed to occur, however, especially in WLANs that use a mix of clients and APs.

Because there is enough bandwidth to support the video stream, the video plays with no problems - as if there were nothing else happening on the WLAN. But if you were little Susie, running your nightly BitTorrent session, you would notice the drop in Torrent download speed.

Of course, if there isn't enough bandwidth to go around, miracles don't occur. Figure 7 shows what happens when the Linksys router is forced to run in 802.11b mode.

Shared data and video stream - 11b WLAN

Figure 7: Shared data and video stream - 11b WLAN

This time, the IxChariot script gets only about 5 Mbps of bandwidth, typical of an 11b connection. So when I start streaming the video - which needs an average of 9 Mbps or bandwidth - at about the 15 second mark, the result is not surprising. The stream tries take as much bandwidth as it needs, but comes up short and an unwatchable video results (Figure 8).

Figure 8: What happens when you run out of bandwidth

Figure 8: What happens when you run out of bandwidth
Wi-Fi System Tools
Check out the new Wi-Fi System Charts, Ranker and Finder!

Featured Sponsors



Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

Found the following in my log today:Jun 20 05:06:47 vpnserver1[25324]: 185.200.118.77:52854 TLS: Initial packet from [AF_INET]185.200.118.77:52854 (vi...
I don't check my router every day, but a few days ago, I used the router app on my phone just for giggles, it found my 86U, but when signing in to it,...
I all,I've just bought a router asus rt-ac68u for my new home.The former firmware inside was 3.0.0.4.384_20308-gead790e.For the moment I am living in ...
Nice insight into the ASIC's and Architecture of Enterprise/Carrier Grade switches one usually finds in the data centers and central offices...https:/...
Hello, This is my first post so please bear with me and I apologize if this is not in the right forum. Anyways was at Walmart and noticed they had the...

Don't Miss These

  • 1
  • 2
  • 3