From owner-freebsd-stable@FreeBSD.ORG Sun Mar 7 21:28:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC40D1065670 for ; Sun, 7 Mar 2010 21:28:40 +0000 (UTC) (envelope-from lists@pingle.org) Received: from willow.pingle.org (willow.pingle.org [68.76.213.30]) by mx1.freebsd.org (Postfix) with ESMTP id A3C328FC0A for ; Sun, 7 Mar 2010 21:28:40 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by willow.pingle.org (Postfix) with ESMTP id B31E211427; Sun, 7 Mar 2010 16:28:39 -0500 (EST) X-Virus-Scanned: amavisd-new at pingle.org Received: from willow.pingle.org ([127.0.0.1]) by localhost (willow.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqOwwbyJQl9H; Sun, 7 Mar 2010 16:28:38 -0500 (EST) Received: from [192.168.10.10] (hpcw.hpcisp.com [68.76.213.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by willow.pingle.org (Postfix) with ESMTPSA id DA31D1141C; Sun, 7 Mar 2010 16:28:37 -0500 (EST) Message-ID: <4B941A85.5050809@pingle.org> Date: Sun, 07 Mar 2010 16:28:37 -0500 From: Jim Pingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Sam Leffler References: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> <20100227124308.GA28213@mx.techwires.net> <5fbf03c21002270501l2e388ec9tbdad684d38609861@mail.gmail.com> <4B89E174.1060802@pingle.org> <1B1F52CC-FF36-4432-9345-73BB673EE7E8@gmail.com> <4B8AAA0B.4010402@pingle.org> <3BA70425-5413-4E04-AA91-85B699B1D8EF@gmail.com> <4B8B25E0.4060604@pingle.org> <5E979157-9E68-4C08-81BD-14255B038D7F@gmail.com> <4B8B2EEA.6010500@pingle.org> <4B8B48E9.70104@pingle.org> <4B940DDC.7080707@errno.com> In-Reply-To: <4B940DDC.7080707@errno.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , freebsd-stable@freebsd.org Subject: Re: FreeBSD-8.0 802.11n support with ath/mwl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 21:28:41 -0000 On 3/7/2010 3:34 PM, Sam Leffler wrote: > Not following the wlanX naming convention will cause confusion for > things like rc config files (I believe). Definitely any tool I touched > expects vap's to be named wlanX. Duly noted. I wasn't aware of just how many issues would arise from straying from that convention. > sysctl net.wlan.X.%parent gives the parent ifnet of a vap; I've > considered many times including this in the ifconfig status. Feel free > to offer a patch that does this. That may be handy in the future. My C skills are a bit rusty but if I decide to go down that road I'll surely share any patches I might come up with. > mwl 11n support broke sometime near the last firmware update and I never > fixed it. I know in particular there are issues with AMPDU and seq#'s > but possible other things too. The fw is rather finicky in how state is > managed and it's likely the host is not in sync causing problems w/ the > ampdu support and rate control algorithm that both operate in the fw. > You should be able to get >100 Mb/s througput on an HT40 channel but I > think I was seeing more like 35-40. Turning off ampdu is usually > helpful to stabilize operation. I'll have to try that next chance I get. I did manage to get more antenna pigtails and now have a total of three attached, but it didn't make a difference. A colleague was able to get an N rate association on his mwl card (108Mbps) with similar settings to mine, but with a different client card. It would seem that the problem may lie in the client card in my case, so I'm also investigating options there at the moment. It's an Intel ABGN 5100 card, in case anyone wonders. I also found the mwlstats and mwldebug programs which are in the src tree but not built with the system. A simple "cd /usr/src/tools/tools/mwl; make all install" built them, but mwldebug didn't seem to work for me. Looking at the code I just need to build a kernel or module while having MWL_DEBUG defined to get the sysctls to show up, but I have not yet tried that as I've had a fairly busy week. I'll see if changing the ampdu settings make any difference and report back, and hopefully the rebuild with MWL_DEBUG might also help me get a lead if tweaking ampdu doesn't help. Thanks for the reply, Sam. I appreciate the insight. Jim