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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
