On Mar 27, 2008, at 11:30 AM, Ricardo Carrano wrote: > (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 ? > > I also see a strong correlation between data rate and path length. > > Only 3.3% of the direct traffic (one hop) was transmitted at 1Mbps > > but this percentage jumps to 46% for frames with ttl 3. I believe > > this is an indicator of sanity, but this deserves some more > > thinking. What do you guys think? > > I thought TTL 3 traffic is mostly retransmissions of RREQs. Why only > at the lowest rate ? This might be a sampling artifact. > The active antenna/driver can't keep up with higher packet rates (at > 54 Mbps, short packets come fast). > My analysis had nothing to do with this. It was made over unicast > traffic > (tcp traffic in this case). I am trying to judge the path discovery > mechanism by the results it brings. Ah. > > I assume some of the XOs are placed in another room (not in the > > server room - since there is only 30 there) and this would account > > for at least some of the long paths and lower rates. > > Check the above link, there is even a diagram of the laptop location > (variances from this location are noted in some of the experiments). > Many of the ten laptop tests had all laptops on a single 1.5m x 0.7m > table. > My comment was based on the diagram. Because there is only 30 > laptops in the server room. So, some are on the other room (at the > right hand, it seems). This is one very important factor. For each experiment, I list the laptops used. The diagram is labelled with what laptops are on each table. In general, they go sequentially up and back along the table (X50 is across from X59, X51 is across from X58, etc. I made a set of tests that varied mainly in physical location of the participants (I was curious about near field effects between the laptop antennas.) The results are shown in that chart. > > So, I really don't see such a big pathology (some, maybe) in the > > protocol decisions. Burstiness caused by path discovery traffic > > seems much more scary to me. > > Can this algorithm be tweaked ? Cerebro to the rescue ? > > As Michalis pointed out, the driver and the firmware support this: > > iwpriv msh0 get_link_costs > iwpriv msh0 set_link_costs > > will give/set associated metrics for the 54, 36, 11 and 1 Mbps RREQs. 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. 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 ? wad _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
