<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
>  (Time to stop using active antennas for packet capture ?)<br>
><br>
> Please check with another sniffer if you can still listen to<br>
> beacons from this active antenna. If so, please stop using it as a<br>
> sniffer. Please take a look at #6709.<br>
<br>
</div>I already logged with multiple sniffers.   Yes, the beacons are on.<br>
<br>
Thanks for the info.  How do I turn them off manually ?<br>
<div class="Ih2E3d"></div></blockquote><div><br>You would use: "iwpriv eth0 bcn_control 0", but there is #4927<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
</div>Thanks for providing the needed command lines, but I agreed with your<br>
comment that tweaking the weights was likely to be a tedious process<br>
without any guarantee of improvements.<br>
</blockquote><div><br>I believe we will get to the point of metric adjustment (or validation) soon. After some other tunings are finished.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
That question was made more about the retransmission storms arising<br>
from broadcast frames (such as RREQs).  This seems to be a basic<br>
problem with reactive meshes --- what other mechanisms have been<br>
proposed to address this ?    Or should we consider<br>
proactive routing such as that provided by cerebro ?</blockquote><div><br>Some people will say that reactive protocols are bursty and route acquisition time is long. I don't disagree.<br>But I believe we have room for improvement without any radical (and costly) change. The key is to adapt.<br>
We are very focused now on dense clouds (for good reasons), but our parameters are sub-optimal for this scenario.<br><br>In a dense scenario, we should:<br>1 - Eliminate probe responses<br>2 - Increase contention window<br>
3 - Increase route expiration time<br>4 - Increase multicast transmission rate<br><br>My suggestion for the Cambrige testbed is:<br>1 - Validade probe response driver patch submitted by Marvell and implement it<br>2 - Increase contention window from 7,31 ro 31, 1023<br>
3 - Increase route expiration time from 10 to 20 seconds<br>4 - Increase mcast rate from 2 to 11 Mbps.<br><br>All of the above are trade offs and should be considered in dense mesh scenarios only. Based on what I see in my own testbed, they will reduce the duration of bursts and also make you more resilient to them.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
wad<br>
<br>
</blockquote></div><br>