11g vs. 11g - Streaming

By TG Publishing Team, published on November 30, 2003
Source: Tom's Guide US | Keywords: ,
Contents

7. 11g vs. 11g - Streaming

Atheros has said that Broadcom is harping on something common to all 802.11g products and that interference will also be generated by "normal" 802.11g WLANs operating in close proximity. So I first wanted to test to see if this were true.

Since Broadcom used a 2Mbps MPEG stream as part of their Comdex demonstration, I also wanted to include streaming as part of my testing. But I wanted a measure more quantitative than trying to describe the degree of jerkiness in a streaming video of The Matrix.

Fortunately, Chariot includes the ability to simulate video streams, and calculates the Lost Data in a stream. Due to the buffering and error recovery mechanisms built into streaming protocols, it's difficult to directly correlate a Lost Data number to the number and severity of glitches in a streaming video. But it's safe to say that lower Lost Data numbers are better than higher, and using Lost Data as a measurement is a hell of a lot easier than trying to describe how a video is breaking up!

Chariot doesn't include MPEG streams among its test scripts. So I had to make do using the NetMtgv.scr script, which emulates a NetMeeting 2.1 Video stream. I used UDP as the protocol and set the stream rate to 2.048Mbps.

Because the bit rate is limited to 2Mbps, the spectrum generated isn't very wide, which should limit the channel overlap, and therefore the amount of performance degradation.

My first round of tests were run with the following conditions:

Atheros-based test pair set to "normal" 802.11g, channel 6 Broadcom-based 11g test pair on channel 11 2.048Mbps, UDP NetMtgv.scr running on both WLANs 10 feet maximum between WLANs (both APs and STAs [clients]) Broadcom-based WLAN started first, followed by Atheros-based WLAN 10 seconds later. Data sent from STA to AP

Figure 9 shows the throughput plot for the test, which doesn't really tell you much. The blip near the end of the test appears in most tests and is caused by a periodic scan done as part of Broadcom's driver.

Updated December 6, 2003
Broadcom says the periodic glitch is due to a scan done by WinXP's "Zero Configuration" utility, and not by Broadcom's driver.

Figure 10 provides a little more insight since it shows the data lost by each stream, which is the difference between the Bytes sent and Bytes received. The results show 0.041% of data was lost in the Broadcom-based stream and none in the Atheros-based stream. This isn't really very significant, especially since the largest disturbance is due the glitch caused by the Broadcom driver.

I then repeated the same test after moving the Atheros-based WLAN 30 feet and 50 feet away from the Broadcom-based WLAN. Figures 11 and 12 show only the Lost Data plots for those tests, since the throughput plots look pretty much like Figure 9.

Conclusion from the first round of tests:
You probably would never notice interference between two 11g WLANs running video streams at any distance.

Figure 9: Throughput for Atheros 11g vs Broadcom 11g - 2Mbps streams - 10ft
(click on the image for a full-sized view)

Figure 10: Lost Data % for Atheros 11g vs Broadcom 11g - 2Mbps streams - 10ft
(click on the image for a full-sized view)

Figure 11: Lost Data % for Atheros 11g vs Broadcom 11g - 2Mbps streams - 30ft
(click on the image for a full-sized view)

Figure 12: Lost Data % for Atheros 11g vs Broadcom 11g - 2Mbps streams - 50ft
(click on the image for a full-sized view)
Comments | Print | Send to a friend

Related albums

  super-cooled quantum computing  
super-cooled quantum computing

Sponsored links

Comments

Comments are closed on this page.

Sponsored links