Could be rate selection. Ben, a sanity check: is it possible for the device to be associated to an "HT-Only" AP and thus not be able to sent NO_HT packets? Could that be why there might need to be a channel change sometimes? Dan On Sun, Feb 6, 2011 at 12:07 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 02/06/2011 11:59 AM, Felix Fietkau wrote: >> >> On 2011-02-06 8:54 PM, Ben Greear wrote: >>> >>> On 02/06/2011 11:42 AM, Felix Fietkau wrote: >>>> >>>> On 2011-02-06 8:01 PM, Ben Greear wrote: >>>>> >>>>> Current code always sets the channel type to NO_HT when scanning. >>>>> >>>>> From what I can tell, we should be able to send NO_HT packets on >>>>> any channel type, and for passive scanning, it should not matter >>>>> at all what channel-type we are using. >>>>> >>>>> I tested relaxing scanning to use the current channel type >>>>> when scanning on the operating channel, and it seems to >>>>> work. >>>>> >>>>> Does anyone see any problems with this approach? >>>> >>>> One thing you should make sure is that once you're done associating to >>>> an NO_HT or HT20 AP (and you have no other interfaces to consider), the >>>> channel mode must not be HT40 - otherwise it could reduce throughput. >>> >>> That is currently handled correctly by the ieee80211_set_channel_type >>> method, as far as I can tell... >>> >>> Regardless of that, in my multi-vif testing, I see lower throughput when >>> using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP >>> ath9k machine). >>> The VIFS all claim 300Mbps rate. >>> I haven't looked into this any further at this point... >> >> Well, with HT40 you take a hit from not just the busy time of the >> primary channel, but also from the busy time of the extension channel. >> If you have other wifi activity on the extension channel, then it's >> normal that this would reduce throughput. > > There were a few other APs on that channel, but they were not doing any > active work > (just beacons and such). The two ath9k systems were very busy > talking to each other. My typical work-load is STA sending to STA > through the AP. > > So, would that scenario be likely to cause the slowdown that you > mention? > > Thanks, > Ben > >> >> - 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 > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > -- > 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 > -- 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
