2010/12/6 Bruno Randolf <br1@xxxxxxxxxxx>: > On Mon December 6 2010 15:30:00 Jonathan Guerin wrote: >> Hi, >> >> >> I've been doing some investigation into the behaviour of contention >> windows and retransmissions. >> >> Firstly, I'll just describe the test scenario and setup that I have. I >> have 3 Via x86 nodes with Atheros AR5001X+ cards. They are tethered to >> each other via coaxial cables, into splitters. They have 20dB of fixed >> attenuation applied to each antenna output, plus a programmable >> variable attenuator on each link. One node acts as a sender, one as a >> receiver, and one simply runs a monitor-mode interface to capture >> packet traces. All 3 are running kernel version 2.6.37-rc2. The sender >> and receiver are configured as IBSS stations and are tuned to 5.18 >> GHz. >> >> Here's a really dodgy ASCII diagram of the setup: >> >> S-----[variable attenuator]-----R >> >> >> >> +------------M-------------------------+ >> >> where S is the Sender node, R is the Receiver node and M is the >> Monitoring capture node. >> >> >> Secondly, I have written a program which will parse a captured pcap >> file from the Monitoring station. It looks for 'chains' of frames with >> the same sequence number, and where the first frame has the Retry bit >> set to false in the header and all following have it set to true. Any >> deviation from this, and the program drops the current chain without >> including it in its stats, and looks for the next chain matching these >> requirements. It averages the amount of time per transmission number >> (i.e. the average of all transmissions which were the first, second, >> third etc. for a unique sequence number). The transmission time of a >> frame is the amount of time between the end of the frame and the end >> of the previous. It tracks these 'chains' of frames with the same >> sequence number. It considers the last transmission number in each >> chain as the 'final' transmission. >> >> Finally, the link is loaded using a saturated UDP flow, and the data >> rate is fixed to 54M and 36M. This is specified in the output. The >> output is attached below. >> >> The output describes the fixed link data rate, the variable >> attenuator's value, the delivery ratio, and the number of transmitted >> packets/s. I've added a discussion per result set. Each line outputs >> the transmission number, the average transmission time for this >> number, the total number of transmissions, the number of frames which >> ended their transmissions at this number (i.e. where the chain ended >> its final transmission - this is equivalent to the retransmission >> value from the Radiotap header + 1), and the average expected >> transmission time for all that particular transmission number in all >> chains. This is calculated using the airtime calculations from the >> 802.11a standard, with the receipt of an ACK frame, as well as a SIFS >> (16us), which is 28us. If the transmission did not receive an ACK, a >> normal ACK timeout is 50 us, but ath5k appears to have this set to 25 >> us, so the value shouldn't be too far out what to expect. >> >> The header to each result refers to the rate it was fixed at, as well >> as the variable attenuation being added to it. The link also has a >> fixed 40dB of attenuation both to protect the cards, as well as give >> the necessary range for the variable attenuator to control link >> quality. >> >> ==> iperf_33M_rate_36M_att_1dB.pcap.txt <== (good link, 100% delivery) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAvg >> 1       477.604980   Â10463  10462      509 >> Overall average: 477.604980 >> >> [Discussion:] Nothing, appears normal. >> >> >> ==> iperf_33M_rate_36M_att_18dB.pcap.txt <== (lossy link, but still >> 100% delivery) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAvg >> 1       476.966766   Â9808      Â8138  Â509 >> 2       550.320496   Â1663      Â1403  Â581 >> 3       697.552917   Â255       218   725 >> 4       1028.756714   37       Â30       Â1013 >> 5       1603.428589   7        7        1589 >> Overall average: 494.514618 >> >> [Discussion:] Nothing, appears normal. Contention window appears to >> double normally. >> >> ==> iperf_33M_rate_36M_att_19dB.pcap.txt <== (lossy link, but still >> 100% delivery) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAvg >> 1       477.510437   Â14893  8653  Â509 >> 2       546.149048   Â6205      Â3624  Â581 >> 3       692.270203   Â2561      Â1552  Â725 >> 4       980.565857   Â1002      Â596   1013 >> 5       1542.079956   400       252   1589 >> 6       2758.693848   147       89       Â2741 >> 7       4971.500000   56       Â32       Â5045 >> 8       4689.043457   23       Â15       Â5045 >> 9       4487.856934   7        3        5045 >> 10      Â442.250000   Â4        3        5045 >> 11      Â488.000000   Â1        1        5045 >> Overall average: 580.976807 >> >> [Discussion:] Contention window appears to double until a plateau from >> 7 through 9. Weirdly, the contention window appears to be drop again >> from 10, but >> there are too few frames to draw a conclusion. >> >> ==> iperf_33M_rate_36M_att_21dB.pcap.txt <== (lossy link, < 1% delivery) >> TXNo ÂAvg           No       ÂFinal  ExpectedAvg >> 1       485.390198   Â1940      Â3     Â509 >> 2       479.113434   Â1922      Â2     Â581 >> 3       479.681824   Â1914      Â0     Â725 >> 4       485.083038   Â1903      Â1     Â1013 >> 5       492.088135   Â1895      Â4     Â1589 >> 6       508.322510   Â1876      Â1     Â2741 >> 7       524.697876   Â1870      Â1     Â5045 >> 8       543.054382   Â1857      Â0     Â5045 >> 9       522.970703   Â1842      Â0     Â5045 >> 10      Â478.204132   Â1837      Â0     Â5045 >> 11      Â476.520782   Â1828      Â0     Â5045 >> 12      Â477.531342   Â1818      Â0     Â5045 >> 13      Â476.743652   Â1810      Â0     Â5045 >> 14      Â478.936554   Â1797      Â0     Â5045 >> 15      Â480.699097   Â1788      Â0     Â5045 >> 16      Â482.734314   Â1784      Â0     Â5045 >> 17      Â491.608459   Â1775      Â0     Â5045 >> 18      Â497.458984   Â1767      Â1     Â5045 >> 19      Â495.067932   Â1752      Â7     Â5045 >> 20      Â478.102417   Â1738      Â295   5045 >> 21      Â475.128845   Â1436      Â1402  5045 >> 22      Â492.692322   Â26       Â0     Â5045 >> 23      Â471.576935   Â26       Â0     Â5045 >> 24      Â466.884613   Â26       Â0     Â5045 >> 25      Â476.269226   Â26       Â0     Â5045 >> 26      Â462.192322   Â26       Â0     Â5045 >> 27      Â480.961548   Â26       Â1     Â5045 >> 28      Â463.600006   Â25       Â24     5045 >> Overall average: 491.068359 >> >> [Discussion:] Contention does not appear to increase, and the number >> of transmission per frame is very large. This behaviour is replicated >> with the 54M scenario when a link is extremely lossy. >> >> ==> iperf_33M_rate_54M_att_1dB.pcap.txt <== (good link, 2400 packets/s) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAverage >> 1       365.551849   Â23957  23935      393 >> 2       409.571442   Â21       Â21       Â465 >> Overall average: 365.590424 >> >> [Discussion: ] Appears relatively normal. >> >> ==> iperf_33M_rate_54M_att_10dB.pcap.txt <== (lossy link, but still >> 100% delivery, 1500 packets/s) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAverage >> 1       364.501190   Â10134  5915  Â393 >> 2       434.138000   Â4196      Â2461  Â465 >> 3       579.482300   Â1721      Â1036  Â609 >> 4       837.005859   Â682       397   897 >> 5       1365.279175   283       155   1473 >> 6       2572.007812   128       81       Â2625 >> 7       4905.195801   46       Â27       Â4929 >> 8       4985.947266   19       Â12       Â4929 >> 9       4627.285645   7        4        4929 >> 10      Â366.000000   Â3        1        4929 >> 11      Â335.500000   Â2        2        4929 >> Overall average: 473.477020 >> >> [Discussion: ] Appears fine, until transmission 10, which appears to >> drop the contention window back to an equivalent first transmission >> value, but not enough frames at this point to draw a conclusion. >> >> ==> iperf_33M_rate_54M_att_11dB.pcap.txt <== (lossy link, but still >> 100% delivery, 680 packets/s) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAverage >> 1       362.082825   Â2149      Â539   393 >> 2       434.672485   Â1606      Â368   465 >> 3       582.795288   Â1231      Â307   609 >> 4       820.347107   Â919       237   897 >> 5       1424.753296   673       194   1473 >> 6       2626.403320   466       143   2625 >> 7       4734.233887   308       83       Â4929 >> 8       4830.244141   217       65       Â4929 >> 9       4449.702637   148       33       Â4929 >> 10      Â360.114044   Â114       36       Â4929 >> 11      Â366.000000   Â78       Â20       Â4929 >> 12      Â460.655182   Â58       Â20       Â4929 >> 13      Â544.184204   Â38       Â9        4929 >> 14      Â893.965515   Â29       Â7        4929 >> 15      Â1361.409058   22       Â8        4929 >> 16      Â2675.285645   14       Â2        4929 >> 17      Â4239.500000   12       Â5        4929 >> 18      Â3198.142822   7        2        4929 >> 19      Â5111.799805   5        3        4929 >> 20      Â1403.000000   2        1        4929 >> Overall average: 1063.129883 >> >> [Discussion: ] Everything appears fine until, once again, transmission >> 10, when the contention windows appears to 'restart' - it climbs >> steadily until 17. After this point, there are not enough frames to >> draw any conclusions. >> >> ==> iperf_33M_rate_54M_att_12dB.pcap.txt <== (lossy link, 6% delivery, >> 400 packets/s) >> Average time per TX No: >> TXNo ÂAvg           No       ÂFinal      ExpectedAvg >> 1       360.460724   Â4482      Â14       Â393 >> 2       366.068481   Â4453      Â16       Â465 >> 3       360.871735   Â4413      Â13       Â609 >> 4       361.535553   Â4386      Â18       Â897 >> 5       367.526062   Â4357      Â60       Â1473 >> 6       360.003967   Â4283      Â3839  Â2625 >> 7       361.778046   Â419       416   4929 >> Overall average: 362.732910 >> >> [Discussion:] This exhibits the same problem as the extremely lossy >> 36M link - the contention window does not appear to rise. Even with >> enough frames to draw a good conclusion at transmission 6, the >> transmission time average (360) is way below the expected average >> (2625). >> ==> END OF OUTPUT <== >> >> The question here is: why does ath5k/mac80211 send out so many >> transmissions, and why does it vary so much based on link quality? >> Additionally, why does it appear to 'reset' the contention window >> after 9 retransmissions of a frame? >> >> Cheers, >> >> Jonathan > > Hi Jonathan! > > This is a very interesting setup and test. I guess nobody has looked so > closely yet... I think this is not necessarily ath5k related, but may be a bug > of mac80211 or minstrel, but not sure yet, of course... > > It's normal, that the CW is reset after the retry limits are reached, this is > what the standard says: > > "The CW shall be reset to aCWmin after every successful attempt to transmit an > MPDU or MMPDU, when SLRC reaches dot11LongRetryLimit, or when SSRC reaches > dot11ShortRetryLimit." (802.11-2007 p261) > > But it seems weird that there are so many retransmissions. The default maximum > numbers of retransmissions should be 7 for short frames and 4 for long frames > (dot11[Short|Long]RetryLimit), and this is what is set as defaults in mac80211 > (local->hw.conf.short_frame_max_tx_count). Seems we are getting many > retransmissions from minstel, i added some debug prints: > When ath5k doesn't get retry limits from above it uses the following defaults on dcu. For now i don't think we use local->hw.conf.short_frame_max_tx_count for that so the default is ah_limit_tx_retries (AR5K_INIT_TX_RETRY) but seems it's wrong and we should fix it... /* Tx retry limits */ #define AR5K_INIT_SH_RETRY 10 #define AR5K_INIT_LG_RETRY AR5K_INIT_SH_RETRY /* For station mode */ #define AR5K_INIT_SSH_RETRY 32 #define AR5K_INIT_SLG_RETRY AR5K_INIT_SSH_RETRY #define AR5K_INIT_TX_RETRY 10 > *** txdesc tries 3 > *** mrr 0 tries 3 rate 11 > *** mrr 1 tries 3 rate 11 > *** mrr 2 tries 3 rate 11 > > This seems to be the normal case and that would already result in 12 > transmissions. > > Another thing that strikes me here is: why use multi rate retries if the rate > is all the same? (Ignore the actual value of the rate, this is the HW rate > code). > > Other examples: > > *** txdesc tries 2 > *** mrr 0 tries 9 rate 12 > *** mrr 1 tries 2 rate 13 > *** mrr 2 tries 3 rate 11 > > = 16 transmissions in sum. > > *** txdesc tries 9 > *** mrr 0 tries 3 rate 11 > *** mrr 1 tries 9 rate 8 > *** mrr 2 tries 3 rate 11 > > = 24 transmissions in sum. Again, rate[1] and rate[3] are the same, so why > bother setting it up twice? > > bruno > _______________________________________________ > ath5k-devel mailing list > ath5k-devel@xxxxxxxxxxxxxxx > https://lists.ath5k.org/mailman/listinfo/ath5k-devel > Also on base.c 2408 /* set up multi-rate retry capabilities */ 2409 if (sc->ah->ah_version == AR5K_AR5212) { 2410 hw->max_rates = 4; 2411 hw->max_rate_tries = 11; 2412 } -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ÿ«zW¬³ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
