From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 21:02:20 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2ACEF7B4; Mon, 27 May 2013 21:02:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E019BD04; Mon, 27 May 2013 21:02:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd1b:cc3:22ae:789f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 261104AC1C; Tue, 28 May 2013 01:02:14 +0400 (MSK) Date: Tue, 28 May 2013 01:02:12 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <711055633.20130528010212@serebryakov.spb.ru> To: Adrian Chadd Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: References: <372806514.20130519141024@serebryakov.spb.ru> <1106213329.20130519193856@serebryakov.spb.ru> <1377052407.20130519195416@serebryakov.spb.ru> <5931014.20130519213437@serebryakov.spb.ru> <1596494929.20130519223744@serebryakov.spb.ru> <456290883.20130520124616@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:02:20 -0000 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