On 2010-03-01 11:38 PM, Derek Smithies wrote: > Hi, > Great work on getting this far - it was a huge undertaking. > > Ok, before diving into the code, can we take a quick moment to think on > this. I wonder if you can answer the following questions: > > a)Minstrel worked hard at using information that is good and reliable: - > which is the record of what rates worked, and what rates failed. > Minstrel avoids using things like RSSI (which is not reliable) Yes, I still rely purely on tx status feedback, no RSSI voodoo. > b)You have stated in previous emails that with 802.11n there are too many > rates for minstrels random sampling technique. > > What is the approach taken in 802.11n & minstrel? I remember some comment > about dividing the 802.11n rate set up into groups, and then minstrel does > its thing within the rates of each group. - Do I have the idea here? The previous comments were based on faulty tx status feedback because of an ath9k issue that I resolved in a previous patch. The current implementation still does random sampling, with one exception: each sampling attempt goes to a different MCS group. Other than that, I split up the MCS rates into groups mainly because it's easier to deal with and allows me to calculate raw transmit durations at compile time. I did add some small special cases though. For instance if the code detects that the current transmit rate is failing really quickly on a multi-stream rate, it falls back to the max_tp_rate of a single-stream group, while leaving around enough feedback for EWMA. This reduces the strength of the throughput drop when I disconnect one antenna (which kills off pretty much all of the dual-stream rates immediately). > Where have you tested 802.11n & minstrel? Only at home. I just finished ironing out most of the important bugs today, so this hasn't seen any significant long-term testing yet. > Does 802.11n&minstrel pass the basic test > a) put two nodes on the desk - rate is high > b) move one of the nodes (or remove antenna) - rate should drop > c) move nodes back to the configuration of a) > -rate should go high again Yes, this was my primary test. I also did some tests with removing both antennas and moving the laptop away and back again. I also did quite a few tests switching back and forth between minstrel_ht and the ath9k rate control to compare them as accurately as possible. In HT40, rate adaptation with minstrel is usually a little slower (only a minor difference here, probably caused by the much larger search space), but it's able to deal with sources of interference (e.g. Bluetooth) a lot better. It also reacts much faster to problems with spatial multiplexing, and seems to get a better average throughput in HT20 in my tests. > Does 802.11n&minstrel work well with time? > In other words, is the throughput 10 hours later the same as at the start > of the test? If I force it to single-stream mode, then it seems to be just as reliable at sticking to a specific rate as the legacy implementation. With dual-stream rates it's hard to tell, because the reliability of rates varies quickly, even if the positions is fixed. I do not see any *significant* variations in throughput though. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
