<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;"><br> (Time to stop using active antennas for packet capture ?)</blockquote>
<div><br>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.<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>
<div class="Ih2E3d"><br>
> I also see a strong correlation between data rate and path length.<br>
> Only 3.3% of the direct traffic (one hop) was transmitted at 1Mbps<br>
> but this percentage jumps to 46% for frames with ttl 3. I believe<br>
> this is an indicator of sanity, but this deserves some more<br>
> thinking. What do you guys think?<br>
<br>
</div>I thought TTL 3 traffic is mostly retransmissions of RREQs.  Why only<br>
at the lowest rate ?  This might be a sampling artifact.<br>
The active antenna/driver can't keep up with higher packet rates (at<br>
54 Mbps, short packets come fast).</blockquote><div><br>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.<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>
<div class="Ih2E3d"><br>
> I assume some of the XOs are placed in another room (not in the<br>
> server room - since there is only 30 there) and this would account<br>
> for at least some of the long paths and lower rates.<br>
<br>
</div>Check the above link, there is even a diagram of the laptop location<br>
(variances from this location are noted in some of the experiments).<br>
Many of the ten laptop tests had all laptops on a single 1.5m x 0.7m<br>
table.</blockquote><div><br>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.<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><div class="Ih2E3d"><br>
> So, I really don't see such a big pathology (some, maybe) in the<br>
> protocol decisions. Burstiness caused by path discovery traffic<br>
> seems much more scary to me.<br>
<br>
</div>Can this algorithm be tweaked ?   Cerebro to the rescue  ?<br>
</blockquote><div><br>As Michalis pointed out, the driver and the firmware support this:<br><br>iwpriv msh0 get_link_costs<br>iwpriv msh0 set_link_costs<br><br>will give/set associated metrics for the 54, 36, 11 and 1 Mbps RREQs.<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;"><br>
Evenin',<br>
wad<br>
<div><div></div><div class="Wj3C7c"><br>
> On Tue, Mar 25, 2008 at 9:52 PM, John Watlington <<a href="mailto:wad@laptop.org">wad@laptop.org</a>><br>
> wrote:<br>
><br>
> The firmware behavior that seemed broken to me was the fact that<br>
> during the barrages the school<br>
> server kept trying to set up 3 or 4 hop routes.  I contend that the<br>
> routing algorithm is flawed in some<br>
> basic way which leads to it favoring multiple hops when faced with<br>
> congestion (which makes<br>
> the congestion worse).   This is even predictable: when faced with a<br>
> high noise floor, closer<br>
> hops will perform better.<br>
><br>
> Changing the expiry time will help, but it doesn't address the root<br>
> cause.  In particular, the<br>
> initial barrages are currently only around two expiry times long!<br>
><br>
> Can we change the algorithm to be weighed more heavily in favor of a<br>
> minimal hop count ?<br>
> wad<br>
><br>
> On Mar 25, 2008, at 8:41 PM, Ricardo Carrano wrote:<br>
><br>
> > The test consists of 10 nodes pinging the multicast address<br>
> > <a href="http://224.0.0.1" target="_blank">224.0.0.1</a> in a quiet environment (< -96dbm noise floor).<br>
> > We vary the expiration time for route entries.<br>
> ><br>
> > EXP TIME%RREQs%RREPsavg Path lengh% Retransmissions<br>
> > 10.60.021.330.65<br>
> > 50.550.021.310.61<br>
> > 100.50.021.220.6<br>
> > 150.430.011.20.6<br>
> > 200.390.011.120.59<br>
> > 300.290.011.120.6<br>
> > 600.210.011.090.62<br>
> > 3000.270.011.090.61<br>
> ><br>
> > EXP TIME = route expiration time in seconds<br>
> > %RREQs, %RREPs = percentage of this kind of frames in the capture<br>
> > Avg Path lengh = the average size of paths between source and<br>
> > destination of unicast traffic<br>
> > % of retransmissions = frames with retry bit on<br>
> ><br>
> > Comments:<br>
> > * Retry rate is high (contention window was left with the default<br>
> > values - so it could be half of that). But the important is that is<br>
> > kept constant (around 60%) indicating that expiration of routes did<br>
> > not hurt delivery rate (though the nodes were stationary).<br>
> > * The nodes are within a small area (table size), so one would<br>
> > expect avg path lengh to be closer to 1. But it is interesting to<br>
> > note that increasing expiration time leads to more reasonable path<br>
> > lengths (with +20 seconds, no path was registered with more than 3<br>
> > hops but with -20 seconds 6% to 8% of the paths would have 3 or<br>
> > more hops.)<br>
> > * 300  seconds and 1 second are there just for setting limits.<br>
> ><br>
> ><br>
> > On Tue, Mar 25, 2008 at 8:11 PM, Ricardo Carrano<br>
> > <<a href="mailto:carrano@laptop.org">carrano@laptop.org</a>> wrote:<br>
> > I've taken a look at the capture for 0321D.<br>
> ><br>
> > What I see is a clearly congested scenario with a clear root cause:<br>
> > path discovery involving the school server [1]<br>
> > This accounts for 71% of the captured frames and analysis on a<br>
> > millisecond resolutions reveals many saturated periods.<br>
> ><br>
> > So, my guess is that RREPs to the failing nodes are not coming<br>
> > through due to congestion (btw, they do evententually, by the end<br>
> > of the capture, what indicates a transitory condition).<br>
> ><br>
> > We have a scenario where there is concentration of traffic towards<br>
> > a point (the school server) and no mobility. Increasing the route<br>
> > expiration time from 10 to 20 seconds will bring a lot of<br>
> > improvement. This is another example of the adaptiveness we need<br>
> > in the presence of a school server.<br>
> ><br>
> > I've been studying the impact of this and found out that there is<br>
> > an interesting side effect. When you increase route expiring time<br>
> > you reduce average route length (though I fail to see why) (I will<br>
> > send some data in another message).<br>
> ><br>
> > I would like to study the data more carefully before publishing,<br>
> > but test D0321 results clearly demonstrate that  we need to be less<br>
> > chatty in our path discovery if we want to have 40 nodes and a<br>
> > school server.<br>
> ><br>
> > We have two ways of achieving so:<br>
> > 1 - Reduce the RREQ barrage (from 4 to 3 frames, for instance)<br>
> > 2 -  Increase route expire time<br>
> ><br>
> > Option 1 would involve changes in the firmware. Option 2 is an easy<br>
> > test to perform (iwpriv).<br>
> ><br>
> > In short I suggest this tweak.<br>
> ><br>
> > [1] wlan_mgt.fixed.action_type == 1 and wlan contains<br>
> > 00:50:43:28:26:2d<br>
> ><br>
> > --<br>
> > Ricardo Carrano<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Mar 25, 2008 at 12:43 PM, John Watlington <<a href="mailto:wad@laptop.org">wad@laptop.org</a>><br>
> > wrote:<br>
> ><br>
> > On Mar 25, 2008, at 11:59 AM, Ricardo Carrano wrote:<br>
> ><br>
> > > Wad,<br>
> > ><br>
> > > I will insist in #6589 because it seems key to the problem.<br>
> > > For all I've seen, it cannot be caused by stressing. It is<br>
> > > something that fails at boot time. So, it would not be a protocol<br>
> > > issue, but a bug in driver/firmware.\<br>
> ><br>
> > The reason I don't believe it is #6589 (as it is currently<br>
> described)<br>
> > is that it<br>
> > is the school server that is not responding (well) to the path<br>
> > request of failing<br>
> > laptops.  But other laptops are succesfull in getting a response<br>
> from<br>
> > the<br>
> > server at the same time.   What I'm seeing in the traces is that the<br>
> > server<br>
> > responds occasionally to failing laptops, but selects a four hop<br>
> path<br>
> > instead<br>
> > of the direct path which it uses for working laptops.<br>
> ><br>
> > For example, see:  <a href="http://wiki.laptop.org/go/" target="_blank">http://wiki.laptop.org/go/</a><br>
> Collab_Network_Test_0321D<br>
> ><br>
> > > Other than that, I agree that we need some tweaking, and am<br>
> working<br>
> > > on them now. Setting a bigger contention window, for instance, is<br>
> > > definitely worth trying. (please see below).<br>
> > ><br>
> > > The problem with tunning is that bugs get in the way and mask<br>
> > > everything. So we really really need to get rid of #6589.<br>
> ><br>
> > Agreed.<br>
> ><br>
> > > ======================================<br>
> > > Here are some results for the tests with CW settings.<br>
> > ><br>
> > > Setup:<br>
> > > * Build 695 + firmware 22.p6.<br>
> > > * 10 XOs in a quiet environment (noise floor < -96dbm)<br>
> > > * The 10 XOs pinging multicast address <a href="http://224.0.0.1" target="_blank">224.0.0.1</a> (100 pings each,<br>
> > > default size, default interval).<br>
> > > * Test was repeated 3 times (alternated)<br>
> > ><br>
> > > Summary:<br>
> > > * There is strong correlation between the retry bit and CW<br>
> settings<br>
> > > * Frames with retry bit set dropped from 12.4% to 5.7% when the CW<br>
> > > size was increased.<br>
> > > * For this particular test delivery rates improved with big CW<br>
> > > (from 86% to 92%)<br>
> > ><br>
> > ><br>
> > > Retry bit<br>
> > > =========<br>
> > ><br>
> > > Default CW (CWmin = 7, CWmax = 31)<br>
> > > run 1: 7588/62109 12.2%<br>
> > > run 2: 7312/58398 12.5%<br>
> > > run 3: 7566/60949 12.4%<br>
> > ><br>
> > > Big CW (CWmin = 31, CWmax = 1023)<br>
> > > run 3: 3734/64585 5.8%<br>
> > > run 3: 4042/69035 5.9%<br>
> > > run 3: 3909/70745 5.5%<br>
> > ><br>
> > > ping success rate:<br>
> > > ==================<br>
> > > Default CW (CWmin = 7, CWmax = 31)<br>
> > > run 1: 86%<br>
> > > run 2: 85%<br>
> > > run 3: 88%<br>
> > ><br>
> > > Big CW (CWmin = 31, CWmax = 1023)<br>
> > > run 1: 90%<br>
> > > run 2: 95%<br>
> > > run 3: 91%<br>
> > ><br>
> > > Retries for echo replies:<br>
> > > =================<br>
> > > Default CW: 4260 in 7214 (59%)<br>
> > > Big CW: 2004 in 7235 (28%)<br>
> > ><br>
> > > Cheers!<br>
> > > Ricardo Carrano<br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>