[rft] please test -HEAD ath; lots of TX changes

[Adrian Chadd]

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 <lev at freebsd.org> 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 <lev at FreeBSD.org>