cvs commit: src/sys/dev/usb if_ural.c if_uralvar.h

Sam Leffler sam at
Sun Nov 20 18:18:01 GMT 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.


More information about the cvs-src mailing list