Hi all, Now that I have a live, convenient way of visualising the rate control data, I decided to do a bit of digging into why HT rate recovery is so slow.
Here's what I've found: * the default EWMA smoothing rate (95) is resistant to change - both temporary hiccups in the environment AND sudden improvements in the environment; * the sampling was occuring across the whole set of MCS rates - and there's potentially a LOT of them!; * i was avoiding sampling rates that were failing (but not enough to fail the WHOLE aggregate frame) - which unfortunately meant that it would take up to 10 seconds to start considering sampling those rates and I'd only ever sample them once every 10 seconds. The last one is the kicker. I inserted some logic to delay sampling HT rates whose average TX time were 10% higher than the current best HT rate. Unfortunately this meant I only sampled it once every 10 seconds and would do that until the average TX time dropped to with 10% of the best rate. This could take a looong time. So, with this patch, HT rate control seems to behave slightly more usefully in changing environments. It may not "stay" on a high rate in the face of temporary interference but it's likely "good enough" for most situations. It definitely fixes the HT rate _recovery_ issues that I see. Now if you really _DO_ want the rate control code to stick with a higher rate in the face of some errors and get that little bit more TCP/UDP throughput, please help me test this and then I'll give you some little tasks to research and code up. Barring any real significant performance drops in my testing over the next couple days or any weird reports from you users, I plan on committing this rate control change by the weekend. Thanks, Adrian
20120912-sample-ht-fixes.diff
Description: Binary data
_______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
