From owner-freebsd-wireless@FreeBSD.ORG Mon May 20 08:46:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2748BA30; Mon, 20 May 2013 08:46:40 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D85583C4; Mon, 20 May 2013 08:46:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:1d62:14ca:3c29:bff9]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 868CD4AC57; Mon, 20 May 2013 12:46:37 +0400 (MSK) Date: Mon, 20 May 2013 12:46:16 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <456290883.20130520124616@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> 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, 20 May 2013 08:46:40 -0000 Hello, Adrian. You wrote 20 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 0:27:52: AC> Right, but you're likely seeing a different issue to "hardware TXQ is s= tuck." AC> I think we've solved that. What we're likely seeing now is some odd AC> buffer exhaustion issues that I haven't yet seen in the driver. -HEAD AC> is supposed to be limiting how many ath_buf's are queued per node AC> _just_ so this particular issue doesn't occur. But it sounds like this AC> isn't entirely working. ...and management frames, which is needed to re-key station failed to transmit and station de-associated, do I understand this right? AC> Now, as for the rate related stuff - yes, MCS15 is actually giving AC> high (99-100%) success rates. But it may not be transmitting MCS15 AC> very often. How busy is the air? Compile up athsurvey and run that Typically air is very busy in my apartments. I'm living in multi-store multi-apartment building and here are A LOT of private WiFi networks. Number of them are changing according to time of day (it looks like many people TURN OFF their routers/APs when they are not at home), but at night here are 30-35 networks in 2.4Ghz, and at morning, when I run tests, 15 WiFi networks at range is not unusual. AC> whilst you're doing a test. I'll try it. AC> I'm going to tidy up the transmit path a little more before I start AC> working on trying to diagnose why you're seeing the behaviour you are. AC> But we'll get to it, I promise. :) Ok. I want notice, that sometimes (typically AFTER problems with de/re-association) it pick ups higher rates and then I see 125-150Mbit/s UDP stream (it is not full 300Mbit/s, but much better). So, looks like problem is not only with busy environment. AC> If you see any other transmit queue stuck issues then please let me AC> know. I want high confidence that we've solved those before I move AC> onto the next stuff. Ok. AC> Thanks for all your patience! Thanks for all our hard work! --=20 // Black Lion AKA Lev Serebryakov