Date: Sun, 20 Nov 2005 10:16:45 -0800 From: Sam Leffler <sam@errno.com> To: Damien Bergamini <damien.bergamini@free.fr> 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 Message-ID: <4380BD8D.7010408@errno.com> In-Reply-To: <03f501c5ede9$c46874b0$0300a8c0@COMETE> References: <200511182137.jAILb2Am040002@repoman.freebsd.org> <43800AA9.1020700@errno.com> <03f501c5ede9$c46874b0$0300a8c0@COMETE>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4380BD8D.7010408>