From owner-cvs-all@FreeBSD.ORG Sun Nov 20 18:18:01 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 395FF16A41F; Sun, 20 Nov 2005 18:18:01 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id D760B43D53; Sun, 20 Nov 2005 18:18:00 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.192] ([10.0.0.192]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jAKIHupU006749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2005 10:17:58 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4380BD8D.7010408@errno.com> Date: Sun, 20 Nov 2005 10:16:45 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Bergamini References: <200511182137.jAILb2Am040002@repoman.freebsd.org> <43800AA9.1020700@errno.com> <03f501c5ede9$c46874b0$0300a8c0@COMETE> In-Reply-To: <03f501c5ede9$c46874b0$0300a8c0@COMETE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb if_ural.c if_uralvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2005 18:18:01 -0000 Damien Bergamini wrote: > | Damien Bergamini wrote: > | > damien 2005-11-18 21:37:02 UTC > | > > | > FreeBSD src repository > | > > | > Modified files: > | > sys/dev/usb if_ural.c if_uralvar.h > | > Log: > | > Second part of the AMRR commit. > | > Enable automatic rate adaptation in BSS operating mode. > | > Works great here. Will need a lot of testing though. > | > | This is a big improvement, thank you. Can you say what "works great" > | means? I just tried a couple of ural sticks and they max out at ~13 > | Mb/s for upstream tcp netperf to an 11g ap in close proximity. This > | appears to be the max for the adapter as locking the rate to 54M gets > | about the same (though I don't see any way to get stats on what's going > | on to see if there's room for improvement). > | > | Sam > > > By "works great" I mean that the rate decreases when I move far from > the access point and increases back when I get closer to it. > And when I don't move the rate seems to stay steady. > I'm testing a rate adaptation algorithm there, not becnhmarking the > maximum throughput of the adapter when locked at 54Mbps. When I evaluated amrr in the context of ath it had serious deficiences in responding quickly to changing signal conditions which was one reason why it was never used much (this is typical of an algorithm that uses polled feedback). I wanted to make sure that with ural amrr raised the rate quickly enough with good signal to be competitive with just locking the rate. Since I typically get ~28Mb/s for ath under identical conditions I wanted to verify the throughput was expected since the rate control algorithm could report 54M for the current rate but be changing it constantly or doing something like overdriving the rate for the operating conditions. Sam