<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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<br>
<br>
<div class="moz-cite-prefix">On 02/05/2013 04:38 PM, Ben West wrote:<br>
</div>
<blockquote
cite="mid:CADSh-SOKFj-sj2=m+8HEFiG6PdDz=Qp3m05rh3LX9VPAoqt-FQ@mail.gmail.com"
type="cite">Hi All,<br>
<br>
I'm happy to read that the Hackday just past went well! The <a
moz-do-not-send="true"
href="https://code.commotionwireless.net/projects/commotion/wiki/Hackday-Roadmap-Notes">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 moz-do-not-send="true"
href="https://patchwork.kernel.org/patch/1835531/">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 moz-do-not-send="true"
href="https://patchwork.kernel.org/patch/2050741/">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 moz-do-not-send="true" href="http://gowasabi.net"
target="_blank">http://gowasabi.net</a><br>
<a moz-do-not-send="true" href="mailto:ben@gowasabi.net"
target="_blank">ben@gowasabi.net</a><br>
314-246-9434<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Commotion-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a>
<a class="moz-txt-link-freetext" href="https://lists.chambana.net/mailman/listinfo/commotion-dev">https://lists.chambana.net/mailman/listinfo/commotion-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Dan Staples
Open Technology Institute
<a class="moz-txt-link-freetext" href="https://commotionwireless.net">https://commotionwireless.net</a></pre>
</body>
</html>