Re: [Madwifi-devel] AMRR rate control algorithm causes stations to drop out
Status: Beta
Brought to you by:
otaku
From: Derek S. <de...@in...> - 2008-11-06 20:58:41
|
Hi, there are two issues reported in your email. 1)AMRR rate control algorithm causes stations to drop... 2)Stuck beacons.. Can I suggest that as a comparison point, you run with fixed rate (no rate control algorithm) Do you still get stuck beacon in this mode? Do you still get stations to drop out ? Thanks, Derek. On Thu, 6 Nov 2008, Ahmad Malik wrote: > > > Benoit PAPILLAULT wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Ahmad Malik a écrit : >> >>> Hello all >>> >>> I am stress testing the rate control algorithms in congested scenarios. We >>> have one AP and ten stations connected to this AP. Now if we use AMRR >>> algorithm on all the stations then the connection to the AP is dropped >>> after a while under moderate to high load. >>> >>> The problem seem to be related to stuck beacon problem. My primitive >>> investigation suggests that only during the working of vanilla >>> (non-modified AMRR), the AP side gets Stuck beacon, and restarts the node. >>> This does not happen with Sample or minstrel algorithm. For our work we >>> need to compare AMRR and this stuck becon problem is severely limiting our >>> progress. >>> >>> I will greatly appreciate if someone can help me investigate this further >>> or throw in extra ideas for the reasons why it might be happening. >>> >>> I am using madwifi version 0.9.4 (latest stable release). In addition wifi >>> mac 10.5, phy 6.1, radio 6.3 and Atheros 5212 version are used on the >>> stations. No encryption is allowed and all Atheros specific enhancements >>> (ff, compression etc.) are turned off. The station are running fedora core >>> 6 (linux 2.6.22 kernel). >>> >>> I can give someone access to my testbed consisting of 16 Atheros enabled >>> wireless nodes, if interested. I have also tested it on orbit-lab testbed >>> and it is giving the same problem there. >>> >>> >> >> Hi Ahmad, >> >> This is very interesting. I am not sure this is a stuck beacon problem. >> I've done a similar test with fewer nodes and it happens that STA >> connection are dropped since they are not receiving beacons. >> >> In order to narrow your problem, here are few questions: >> - - could you narrow why STA connection are dropped? Is it initiated by >> the STA or the AP? >> > It seem to be initiated by AP. the prime reason for this is all the stations > lose the connection simultaneously. > >> - - all your STA and AP are running amrr? Or is there a mix? >> > > The stations are running AMRR, while the AP is running Sample. The reason > being the direction of the traffic is from STA to AP. In fact we fix the data > rate at the AP so RCA is not working at AP. >> - - what are the direction of the stream : AP to STA or STA to AP? >> > STA to AP. > >> - - using one node in monitor mode should give more details on what's >> going on? >> > > I have two nodes running in monitor mode ( which combines the traces and > remove duplicity). I can send the graphs of throughput etc, if anyone is > interested. >> - - any kernel logs? >> > > from the kernel logs, I see the SBP occurring which intern resets the nodes > and associated nodes lose the connection, or as you said, as the beacon is > stuck in the AP queue, the associated stations will not be able to see the > beacon and will thus be lost. > > It is really strange as it is only occurring for AMRR, not for sample or > minstrel or Onoe for that matter. >> In my own experiment, I increased "bmiss" a lot to avoid this problem >> (and I was using minstrel, not amrr). >> > You are suggesting I increase the bmiss in stations? I actually increased the > interval for the resetting of node because of stuck beacon problem. Can I > simply turn off the beacon at all in madwifi infrastructure mode? >> Regards, >> Benoit >> > Thanks > > Malik > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFJEZpcOR6EySwP7oIRAvzuAKDizLayt09x4DkC9JMec+FwL1UEZQCfeUEe >> LKhDHUJsqIwCIGODrhAFv5E= >> =Sw6z >> -----END PGP SIGNATURE----- >> > > -- Derek Smithies Ph.D. IndraNet Technologies Ltd. Email: de...@in... ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ |