Monday's Testing

[Ricardo Carrano]

>
> >  (Time to stop using active antennas for packet capture ?)
> >
> > Please check with another sniffer if you can still listen to
> > beacons from this active antenna. If so, please stop using it as a
> > sniffer. Please take a look at #6709.
>
> I already logged with multiple sniffers.   Yes, the beacons are on.
>
> Thanks for the info.  How do I turn them off manually ?
>

You would use: "iwpriv eth0 bcn_control 0", but there is #4927



>
> Thanks for providing the needed command lines, but I agreed with your
> comment that tweaking the weights was likely to be a tedious process
> without any guarantee of improvements.
>

I believe we will get to the point of metric adjustment (or validation)
soon. After some other tunings are finished.



>
> That question was made more about the retransmission storms arising
> from broadcast frames (such as RREQs).  This seems to be a basic
> problem with reactive meshes --- what other mechanisms have been
> proposed to address this ?    Or should we consider
> proactive routing such as that provided by cerebro ?


Some people will say that reactive protocols are bursty and route
acquisition time is long. I don't disagree.
But I believe we have room for improvement without any radical (and costly)
change. The key is to adapt.
We are very focused now on dense clouds (for good reasons), but our
parameters are sub-optimal for this scenario.

In a dense scenario, we should:
1 - Eliminate probe responses
2 - Increase contention window
3 - Increase route expiration time
4 - Increase multicast transmission rate

My suggestion for the Cambrige testbed is:
1 - Validade probe response driver patch submitted by Marvell and implement
it
2 - Increase contention window from 7,31 ro 31, 1023
3 - Increase route expiration time from 10 to 20 seconds
4 - Increase mcast rate from 2 to 11 Mbps.

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.



>
>
> wad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080327/46e32f56/attachment.html>