<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The experts help me figure out my WLAN problems</title>
	<atom:link href="http://www.bohannontech.com/blog/2008/12/02/the-experts-help-me-figure-out-my-wlan-problems/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bohannontech.com/blog/2008/12/02/the-experts-help-me-figure-out-my-wlan-problems/</link>
	<description>Tech Reviews &#38; Commentary</description>
	<lastBuildDate>Fri, 07 Aug 2009 18:40:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>By: Ivan Bohannon</title>
		<link>http://www.bohannontech.com/blog/2008/12/02/the-experts-help-me-figure-out-my-wlan-problems/comment-page-1/#comment-6</link>
		<dc:creator>Ivan Bohannon</dc:creator>
		<pubDate>Sat, 06 Dec 2008 23:38:46 +0000</pubDate>
		<guid isPermaLink="false">http://bohannontech.com/blog2/?p=282#comment-6</guid>
		<description>A friend of my summarized what the experts said, I thought it was helpful

1. name brand wireless gear is not very good at performance.
2. Channel interference causes lots of issues.  Try using  Ch 1, 6, and 11 on 2.4 Ghz
3. Im lousy at wireless performance testing. (he said that not me!)

My theory on the speed ratings is that the numbers claimed are not possible for a single user, they are actually the total possible speed of all users connected to the AP.

So If they say 300Mbps,  that means  7 users will get ~30Mbps each.  Yes I said 210Mbps not 300Mbps, but theres  overhead of the wireless protocols.</description>
		<content:encoded><![CDATA[<p>A friend of my summarized what the experts said, I thought it was helpful</p>
<p>1. name brand wireless gear is not very good at performance.<br />
2. Channel interference causes lots of issues.  Try using  Ch 1, 6, and 11 on 2.4 Ghz<br />
3. Im lousy at wireless performance testing. (he said that not me!)</p>
<p>My theory on the speed ratings is that the numbers claimed are not possible for a single user, they are actually the total possible speed of all users connected to the AP.</p>
<p>So If they say 300Mbps,  that means  7 users will get ~30Mbps each.  Yes I said 210Mbps not 300Mbps, but theres  overhead of the wireless protocols.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ivan Bohannon</title>
		<link>http://www.bohannontech.com/blog/2008/12/02/the-experts-help-me-figure-out-my-wlan-problems/comment-page-1/#comment-5</link>
		<dc:creator>Ivan Bohannon</dc:creator>
		<pubDate>Thu, 04 Dec 2008 19:10:03 +0000</pubDate>
		<guid isPermaLink="false">http://bohannontech.com/blog2/?p=282#comment-5</guid>
		<description>Thanks for your comments Tim, that gives me alot to think about.

Can users improve aggregation on windows clients with registry tweaks ( TCP window size?)  Or is aggregation something thats implementation specific (NDIS driver / NDIS intermediate filter change)</description>
		<content:encoded><![CDATA[<p>Thanks for your comments Tim, that gives me alot to think about.</p>
<p>Can users improve aggregation on windows clients with registry tweaks ( TCP window size?)  Or is aggregation something thats implementation specific (NDIS driver / NDIS intermediate filter change)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Bennington-Davis</title>
		<link>http://www.bohannontech.com/blog/2008/12/02/the-experts-help-me-figure-out-my-wlan-problems/comment-page-1/#comment-4</link>
		<dc:creator>Tim Bennington-Davis</dc:creator>
		<pubDate>Thu, 04 Dec 2008 08:09:44 +0000</pubDate>
		<guid isPermaLink="false">http://bohannontech.com/blog2/?p=282#comment-4</guid>
		<description>There is one thing that was left out of the discussion, which is probably the dominant reason why performance expected varies from performance experienced in the 802.11n world.  Aggregation.

Our company makes the world&#039;s only 802.11 traffic generator/analyzer that is made specifically for testing wireless networks, and we&#039;ve tested all the units referred to (or their close cousins), and can demonstrate data rates on those access points well above the 200 Mbit/sec mark.  It turns out there are three dominant determining factors that can easily be observed, once you test the network with test gear that exceeds the capability of the network:
1.  How much aggregation is the AP providing, and capable of accepting?  Getting to 270 Mbits/sec is possible only when using 1518 byte frames, and aggregating 43 MPDU&#039;s per AMPDU.   Aggregating fewer MPDU&#039;s into an aggregated frame means the number drops quickly.
2.  Frame length.  There is a maximum number of packets/second each AP can handle, regardless of length.   If you can keep packet lengths up near 1500 bytes, you&#039;ll see big throughput numbers.  If you are sending frames less than 100 bytes or so, you will observe a maximum packet rate beginning to be the limiting factor.
3.  How the AP handles frame loss.  It is true that there will be RF interferers.  However, the protocol is actually quite adept at dealing with lost frames and retransmitting them.  But, if, in the process of aggregating, the AP does not do a timely job of retransmitting lost frames in the next AMPDU, the client has to buffer more in order to reorder frames correctly.   With 802.11n, not handling even low levels of frame loss has compounding effect, because loss in one AMPDU rolls into the next AMPDU.

While it is true that MIMO requires appreciable multipath to work effectively, that doesn&#039;t keep 802.11n from delivering on a great deal of its promise just by having laptops close to the AP.  Keep in mind that dropping to one spatial stream (MCS7 and below) will still give you 140 Mbits/sec of media capacity, requiring absolutely no multipath.  It does require channel bonding (40 MHz) and short guard interval, though.  The bottom line is that RF interference rarely turns out to be the thing that prevents the high numbers.

Note that this discussion is all about how the network side of the equation works.  If the client card does a poor job in any of these categories, the network may be wonderful but your net performance will be limited by the slowest member.

That&#039;s why we created to the product we have - to give these manufacturers a way to separate the two variables: client and network - and measure/stress the network accurately.

Tim Bennington-Davis
VP of Engineering
VeriWave, Inc.</description>
		<content:encoded><![CDATA[<p>There is one thing that was left out of the discussion, which is probably the dominant reason why performance expected varies from performance experienced in the 802.11n world.  Aggregation.</p>
<p>Our company makes the world&#8217;s only 802.11 traffic generator/analyzer that is made specifically for testing wireless networks, and we&#8217;ve tested all the units referred to (or their close cousins), and can demonstrate data rates on those access points well above the 200 Mbit/sec mark.  It turns out there are three dominant determining factors that can easily be observed, once you test the network with test gear that exceeds the capability of the network:<br />
1.  How much aggregation is the AP providing, and capable of accepting?  Getting to 270 Mbits/sec is possible only when using 1518 byte frames, and aggregating 43 MPDU&#8217;s per AMPDU.   Aggregating fewer MPDU&#8217;s into an aggregated frame means the number drops quickly.<br />
2.  Frame length.  There is a maximum number of packets/second each AP can handle, regardless of length.   If you can keep packet lengths up near 1500 bytes, you&#8217;ll see big throughput numbers.  If you are sending frames less than 100 bytes or so, you will observe a maximum packet rate beginning to be the limiting factor.<br />
3.  How the AP handles frame loss.  It is true that there will be RF interferers.  However, the protocol is actually quite adept at dealing with lost frames and retransmitting them.  But, if, in the process of aggregating, the AP does not do a timely job of retransmitting lost frames in the next AMPDU, the client has to buffer more in order to reorder frames correctly.   With 802.11n, not handling even low levels of frame loss has compounding effect, because loss in one AMPDU rolls into the next AMPDU.</p>
<p>While it is true that MIMO requires appreciable multipath to work effectively, that doesn&#8217;t keep 802.11n from delivering on a great deal of its promise just by having laptops close to the AP.  Keep in mind that dropping to one spatial stream (MCS7 and below) will still give you 140 Mbits/sec of media capacity, requiring absolutely no multipath.  It does require channel bonding (40 MHz) and short guard interval, though.  The bottom line is that RF interference rarely turns out to be the thing that prevents the high numbers.</p>
<p>Note that this discussion is all about how the network side of the equation works.  If the client card does a poor job in any of these categories, the network may be wonderful but your net performance will be limited by the slowest member.</p>
<p>That&#8217;s why we created to the product we have &#8211; to give these manufacturers a way to separate the two variables: client and network &#8211; and measure/stress the network accurately.</p>
<p>Tim Bennington-Davis<br />
VP of Engineering<br />
VeriWave, Inc.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

