Date: Mon, 27 May 2013 17:10:33 -0400 From: "Adrian Chadd" <adrian.chadd@gmail.com> To: "Lev Serebryakov" <lev@freebsd.org>, "Adrian Chadd" <adrian@freebsd.org> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: [rft] please test -HEAD ath; lots of TX changes Message-ID: <51a3cbd0.2a98320a.4098.28c1@mx.google.com> In-Reply-To: <711055633.20130528010212@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Sweet. I think the problem getting n rates here are likely due to buffer st= arvation 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@freebsd.org> wrote:=20 Hello, Adrian. You wrote 27 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 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=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D186 May 28 00:40:51 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2:= called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D3517 May 28 00:40:52 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2:= called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, 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. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51a3cbd0.2a98320a.4098.28c1>