Hi Dan,<br><br>First off, I believe all of these patches were made against the current version of the compat-wireless library. The first patch did happen to apply cleanly to compat-wireless-2012-09-07 integrated into Attitude Adjustment, but the second patch failed.<br>
<br>This first patch is to add short slot time support to 802.11a adhoc mode (i.e. 5GHz only). Long slots are required for 802.11b/g adhoc mode (i.e. 2.4GHz) to maintain compliant with the standard.<br><br><a href="https://patchwork.kernel.org/patch/1835531/" target="_blank">https://patchwork.kernel.org/patch/1835531/</a><br>
<br>This second patch, on the other hand, will allow short slot slots in 802.11s mode in 2.4GHz and 5.8GHz, which the standard allows.<br><br><a href="https://patchwork.kernel.org/patch/2050741/" target="_blank">https://patchwork.kernel.org/patch/2050741/</a><br>
<br>I do understand Sascha, et al, have expressed criticism for the fact that the 802.11s draft stipulates an arbitrary maximum of 32 nodes per mesh. (Thanks to whichever dastardly telco lobbyist...) However, Antonio of the Robin Mesh project, who has already incorporated 802.11s into this new Meshroot firmware stack, mentioned how this limitation is actually 50 nodes as implemented (??), and that it only applies to the number of neighboring nodes that a particular node can keep in its local table, not that it is a limitation on the total # of nodes in a mesh. I'm still seeking confirmation on this.<br>
<br>Finally, please do note that I have not had the opportunity to test the operation of these patches yet. As for the degree of adoption of 802.11s, besides in the mac80211 / compat-wireless ecosystem of OpenWRT, indeed that is still a work in progress.<br>
<br><div class="gmail_quote">On Fri, Feb 8, 2013 at 9:10 AM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Are those patches for ad-hoc, or are they for 802.11s? If they speed
up ad-hoc throughput, I see no reason not to implement them into
Commotion. But in general, I would be interested in pursuing 802.11s
for Commotion down the line. Do you know how widespread is 802.11s
support is?<br>
<br>
Dan<div class="im"><br>
<br>
<div>On 02/05/2013 04:38 PM, Ben West wrote:<br>
</div>
</div><blockquote type="cite"><div><div class="h5">Hi All,<br>
<br>
I'm happy to read that the Hackday just past went well! The <a href="https://code.commotionwireless.net/projects/commotion/wiki/Hackday-Roadmap-Notes" target="_blank">roadmap
wiki page</a> looks pretty dense, although unfortunately my
suggestion would be to increase its density by adding <b>802.11s
support</b>. My recent work to extract Robin/Cloudtrax
dashboard stuff into a standalone package was part of a larger
effort to get a modern replacement for a Robin nodes. And, this
is what is now prompting my recommendation for 802.11s support.<br>
<br>
Since I have the expectation of remotely re-flashing all the Robin
nodes in the field sometime soon, I did throughput tests for old
vs new to make sure I wouldn't be deploying a regression. And,
looks like 802.11g adhoc meshing, even under Attitude Adjustment
with the latest atheros drivers, is <i>15% to 20% slower</i> than
the ahdemo meshing done by Kamikaze+madwifi based Robin firmware!
This performance penalty appears to come from the fact adhoc mode
require beacons, while ah-demo does not, hence it not being
supported by the 802.11 standard. Furthermore, the mac80211 /
compat-wireless radio drivers currently packaged into OpenWRT
appear to enforce a maximum 1000ms interval for such beacons.<br>
<br>
For 5.8GHz adhoc, a potential work-around is to use short
slot-times as implemented in this patch:<br>
<br>
<a href="https://patchwork.kernel.org/patch/1835531/" target="_blank">https://patchwork.kernel.org/patch/1835531/</a><br>
<br>
2.8GHz adhoc, however, must still use long slot times to remain
standards-compliant. The work-around is that 802.11s meshing can
use short slot times, which this patch implements:<br>
<br>
<a href="https://patchwork.kernel.org/patch/2050741/" target="_blank">https://patchwork.kernel.org/patch/2050741/</a><br>
<br>
While I do admit that doing speed tests on near-obsolete platforms
like ath5k would normally yield diminishing returns, these
slot-time enhancements should apply just as well to ath9k, too.<br>
<br clear="all">
<br>
-- <br>
Ben West
<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
<a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
Commotion-dev mailing list
<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a>
</pre>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Dan Staples
Open Technology Institute
<a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a></pre>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br>
</div>