cvs commit: src/sys/dev/usb if_ural.c if_uralvar.h
Sam Leffler
sam at errno.com
Sun Nov 20 10:18:01 PST 2005
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
More information about the cvs-all
mailing list