Sweet. I think the problem getting n rates here are likely due to buffer starvation when queuing the addba request or response frames.
So I still have to properly fix that. But it'll happen. Cool, keep testing! Adrian Sent from my Palm Pre on AT&T On May 27, 2013 5:02 PM, Lev Serebryakov <[email protected]> wrote: Hello, Adrian. You wrote 27 мая 2013 г., 11:29:29: AC> Would you mind re-testing with what's now in -HEAD? Ok, now I can not "force" connection NOT TO PICK UP n-rates (without disabling N on sever or client). Performance is better, than usual (150-180Mbit/s UDP), and SOMETIMES here are such messages: May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=0, bar_wait=0, bar_tx=0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:9e:c2: TID=0, bar ready May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2: TID=0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2: TID=0, new BAW left edge=186 May 28 00:40:51 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2: called; txa_tid=0, atid->tid=0, status=0, attempts=1 May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f:9e:c2: TID=0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=0, bar_wait=0, bar_tx=0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:9e:c2: TID=0, bar ready May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2: TID=0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2: TID=0, new BAW left edge=3517 May 28 00:40:52 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2: called; txa_tid=0, atid->tid=0, status=0, attempts=1 May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f:9e:c2: TID=0, called Which correlates with dropping of bandwidth to 90Mbit/s for one second. But no re-association problems, no "20-30Mbit/s" problem. And I've tried to power-cycle client and AP, it still pick up N rates from first packet now! When I disable N on client, it shows stable 30Mbit/s (no 54m though :)), but still no de/re-association problems for 600 seconds. But, I stress this out: there was NO way to get non-N rates when N was enabled on both ends, there was NO auth/association problems for several 600-seconds runs. And, yes, in my previous experiments, auth/association problems were only in situation when two N-enabled parties used non-N rates. -- // Black Lion AKA Lev Serebryakov <[email protected]> _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "[email protected]"
