src-test2/sys/dev/ath/ath_rate/sample/sample.c, branch stable/10 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=stable%2F10 2013-02-27T04:33:06Z I give up - just throw the EWMA update into the normal update_stats() 2013-02-27T04:33:06Z Adrian Chadd adrian@FreeBSD.org 2013-02-27T04:33:06Z urn:sha1:ee563d630b65f71d2d1a2dd7c084040c945d1be0 routine. There were still corner cases where the EWMA update stats are being called on a rix which didn't have an intermediary stats update; thus no packets were counted against it. Sigh. This should fix the crashes I've been seeing on recent -HEAD. Update the EWMA statistics for each intermediary rate as well as the final 2013-02-26T10:24:49Z Adrian Chadd adrian@FreeBSD.org 2013-02-26T10:24:49Z urn:sha1:38fda92679e6b688e18d12435e82b97f699a8549 rate. This fixes two things: * The intermediary rates now also have their EWMA values changed; * The existing code was using the wrong value for longtries - so the EWMA stats were only adjusted for the first rate and not subsequent rates in a MRR setup. TODO: * Merge the EWMA updates into update_stats() now.. I've had some feedback that CCK rates are more reliable than MCS 0 2012-10-31T06:35:50Z Adrian Chadd adrian@FreeBSD.org 2012-10-31T06:35:50Z urn:sha1:bf57b7b2ce917f824aadacdcdb900c21c0ebf3e6 in some very degenerate conditions. However, until ath_rate_form_aggr() is taught to not form aggregates if ANY selected rate is non-MCS, this can't yet be enabled. So, just add a comment. Improve performance of the Sample rate algorithm on 802.11n networks. 2012-09-17T01:09:17Z Adrian Chadd adrian@FreeBSD.org 2012-09-17T01:09:17Z urn:sha1:e69db8df7d773db5d6efd99fb5165d7d777b626a * Don't treat high percentage failures as "sucessive failures" - high MCS rates are very picky and will quite happily "fade" from low to high failure % and back again within a few seconds. If they really don't work, the aggregate will just plain fail. * Only sample MCS rates +/- 3 from the current MCS. Sample will back off quite quickly, so there's no need to sample _all_ MCS rates between a high MCS rate and MCS0; there may be a lot of them. * Modify the smoothing rate to be 75% rather than 95% - it's more adaptive but it comes with a cost of being slightly less stable at times. A per-node, hysterisis behaviour would be nicer. Improve the sample rate logging. 2012-08-27T20:30:07Z Adrian Chadd adrian@FreeBSD.org 2012-08-27T20:30:07Z urn:sha1:f6fd8c7af8e8645fbad6b8474cda6d834d7c05f5 Fix build 2012-08-15T15:53:27Z Konstantin Belousov kib@FreeBSD.org 2012-08-15T15:53:27Z urn:sha1:a055e7ceb48de82e8b682f6036e99704383072dd Extend the sample mask from 32 bits to 64 bits. 2012-08-15T07:10:10Z Adrian Chadd adrian@FreeBSD.org 2012-08-15T07:10:10Z urn:sha1:193bfa21eae2c3cc1660fa6aca85ee2e7a9ccf5d This is required to support > MCS15 as more than 32 bit rate entries are suddenly available. This is quite messy - instead of doing typecasts at each mask operation, this should be migrated to use a macro and have that do the typecast. Fix a case of "mis-located braces". 2012-08-01T00:18:02Z Adrian Chadd adrian@FreeBSD.org 2012-08-01T00:18:02Z urn:sha1:9f579ef85daa47b50a6c6c2477c812804339a15e PR: kern/170302 Allow 802.11n hardware to support multi-rate retry when RTS/CTS is 2012-07-31T23:54:15Z Adrian Chadd adrian@FreeBSD.org 2012-07-31T23:54:15Z urn:sha1:af01710118a6bf87eff0141f5dd46fd1c487e9b1 enabled. The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it. Tested: * AR9280, STA PR: kern/170302 Introduce a rate table TLV so rate table statistics consumers 2012-07-20T02:17:48Z Adrian Chadd adrian@FreeBSD.org 2012-07-20T02:17:48Z urn:sha1:be4f96a6b7ff02315471a3d5544c7a37d59e12cf know how to map rix -> rate code.