Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On Mon, Apr 22, 2013 at 12:15:56PM +0200, Felix Fietkau wrote: > On 2013-04-22 12:08 PM, Simon Wunderlich wrote: > > Hey Felix, > > > > just wanted to bump on this issue again, as it has not been applied > > yet - the patch seems still valid, and Mathias results appear to show > > that as well. What do you think? > Looks ok to me, let's get it merged. I don't seem to have it in my queue. Could someone resend it? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On 2013-04-22 12:08 PM, Simon Wunderlich wrote: > Hey Felix, > > just wanted to bump on this issue again, as it has not been applied > yet - the patch seems still valid, and Mathias results appear to show > that as well. What do you think? Looks ok to me, let's get it merged. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
Hey Felix, just wanted to bump on this issue again, as it has not been applied yet - the patch seems still valid, and Mathias results appear to show that as well. What do you think? Thanks, Simon On Fri, Dec 07, 2012 at 01:35:49PM +0100, Mathias Kretschmer wrote: > Hi all, > > On 10/30/2012 01:43 PM, Felix Fietkau wrote: > >On 2012-10-30 1:07 PM, Simon Wunderlich wrote: > >>From: Mathias Kretschmer > >> > >>According to 802.11-2007 17.3.8.6 (slot time), the slot time should > >>be increased by 3 us * coverage class. The code only increased the > >>ack timeout, which is fixed by this patch. > >> > >>We have noticed in our long shot scenario that we see less collisions > >>with this patch. > >At some point I had the slot time increase in the driver, but noticed a > >massive throughput degradation on 10-20 km links. Leaving the slot time > >alone and changing only the ACK timeout fixed this. What distances did > >you test? > > > >- Felix > > > > We've run some tests on a 5km .11a link to verify the proper > functioning of this patch (slot time depending on coverage class) > and the recent patch to ensure the shorter (9us) slot time is used > in .11a adhoc mode. > > According to the standard, the slot time should be calculated as follows: > > slottime = 9us + 3 * ah->coverage_class; > > For our link, this would be > > slottime = 9 us + 3 * 10 = 39 us. (coverage class 10: up to 4950 m) > > If you look at the below TSFT histogram and try to determine the peaks > (first column: diffTime, second column: frameCount), the slot time > turns out to be roughly 39us, which fits pretty nicely with the > expected result. > > The TCP throughput (wget -O /dev/null) was very constant between 1.7 > and 1.8 MByte/s. Which, I'd say, is pretty decent for such a link > (without TxOp, etc). > > Similar measurements for a 10km link, reveal a slot time of about > 71us, which also matches the theoretical figure pretty well: > > slottime = 9us + 3 * 21 = 72 > > Therefore, both patches seem to ensure a proper MAC timing while > yielding proper throughput. > > Cheers, > > Mathias > > > > === TSFT Histogram (times in us) of 00:00:00:00:00:00, age 66s === > 411,945 > 412,5921 > 413,1534 > 450,1271 > 451,4286 > 452,1804 > 490,5592 > 491,731 > 528,773 > 529,3482 > 530,1177 > 567,693 > 568,3071 > 569,1022 > 599,552 > 607,3659 > 608,486 > 637,266 > 638,737 > 639,437 > 645,782 > 646,2103 > 647,929 > 677,1525 > 678,560 > 684,463 > 685,2337 > 686,589 > 715,276 > 716,1630 > 717,704 > 754,424 > 755,1518 > 756,889 > 794,2347 > 795,796 > 832,420 > 833,1800 > 834,891 > 975,315 > 1014,329 > 1015,257 > > > > signature.asc Description: Digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
Hi all, On 10/30/2012 01:43 PM, Felix Fietkau wrote: > On 2012-10-30 1:07 PM, Simon Wunderlich wrote: >> From: Mathias Kretschmer >> >> According to 802.11-2007 17.3.8.6 (slot time), the slot time should >> be increased by 3 us * coverage class. The code only increased the >> ack timeout, which is fixed by this patch. >> >> We have noticed in our long shot scenario that we see less collisions >> with this patch. > At some point I had the slot time increase in the driver, but noticed a > massive throughput degradation on 10-20 km links. Leaving the slot time > alone and changing only the ACK timeout fixed this. What distances did > you test? > > - Felix > We've run some tests on a 5km .11a link to verify the proper functioning of this patch (slot time depending on coverage class) and the recent patch to ensure the shorter (9us) slot time is used in .11a adhoc mode. According to the standard, the slot time should be calculated as follows: slottime = 9us + 3 * ah->coverage_class; For our link, this would be slottime = 9 us + 3 * 10 = 39 us. (coverage class 10: up to 4950 m) If you look at the below TSFT histogram and try to determine the peaks (first column: diffTime, second column: frameCount), the slot time turns out to be roughly 39us, which fits pretty nicely with the expected result. The TCP throughput (wget -O /dev/null) was very constant between 1.7 and 1.8 MByte/s. Which, I'd say, is pretty decent for such a link (without TxOp, etc). Similar measurements for a 10km link, reveal a slot time of about 71us, which also matches the theoretical figure pretty well: slottime = 9us + 3 * 21 = 72 Therefore, both patches seem to ensure a proper MAC timing while yielding proper throughput. Cheers, Mathias === TSFT Histogram (times in us) of 00:00:00:00:00:00, age 66s === 411,945 412,5921 413,1534 450,1271 451,4286 452,1804 490,5592 491,731 528,773 529,3482 530,1177 567,693 568,3071 569,1022 599,552 607,3659 608,486 637,266 638,737 639,437 645,782 646,2103 647,929 677,1525 678,560 684,463 685,2337 686,589 715,276 716,1630 717,704 754,424 755,1518 756,889 794,2347 795,796 832,420 833,1800 834,891 975,315 1014,329 1015,257 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On Tue, Oct 30, 2012 at 02:24:21PM +0100, Felix Fietkau wrote: > [...] > > When I ran the test, the throughput degradation was so big that the > links became almost useless. It was a long time ago, so maybe this was > caused by another bug that has been fixed since. I will run another test > with this patch in a current version... Felix, did you have the chance to run another test on your link with this patch? Would be interesting to know if it makes any difference. :) Thanks, Simon signature.asc Description: Digital signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On 10/30/2012 02:24 PM, Felix Fietkau wrote: > On 2012-10-30 2:00 PM, Mathias Kretschmer wrote: >> On 10/30/2012 01:43 PM, Felix Fietkau wrote: >>> On 2012-10-30 1:07 PM, Simon Wunderlich wrote: From: Mathias Kretschmer According to 802.11-2007 17.3.8.6 (slot time), the slot time should be increased by 3 us * coverage class. The code only increased the ack timeout, which is fixed by this patch. We have noticed in our long shot scenario that we see less collisions with this patch. >>> At some point I had the slot time increase in the driver, but noticed a >>> massive throughput degradation on 10-20 km links. Leaving the slot time >>> alone and changing only the ACK timeout fixed this. What distances did >>> you test? >> >> about 11km. did you test UDP (unidirectional) or TCP (bidirectional) >> throughput ? > I always use TCP, because UDP tests are too unrealistic to estimate real > performance. bidirectional UDP traffic (iperf or preferably mgen) is a good indicator for problems, because there's no flow control that backs off. depends on the use case, of course. >> The larger slot time will increase the channel access overhead which should >> impact >> unidirectional throughput. >> >> With bidirectional traffic, the larger slottime should help to minimize >> collisions >> on loaded links. Overall this seems to increase the net throughput for us, >> especially in higher access categories (smaller backoff windows). > When I ran the test, the throughput degradation was so big that the > links became almost useless. It was a long time ago, so maybe this was > caused by another bug that has been fixed since. I will run another test > with this patch in a current version... we will also test this again. Currently, I can't access those links. Cheers, Mathias > - Felix > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On 10/30/2012 01:43 PM, Felix Fietkau wrote: > On 2012-10-30 1:07 PM, Simon Wunderlich wrote: >> From: Mathias Kretschmer >> >> According to 802.11-2007 17.3.8.6 (slot time), the slot time should >> be increased by 3 us * coverage class. The code only increased the >> ack timeout, which is fixed by this patch. >> >> We have noticed in our long shot scenario that we see less collisions >> with this patch. > At some point I had the slot time increase in the driver, but noticed a > massive throughput degradation on 10-20 km links. Leaving the slot time > alone and changing only the ACK timeout fixed this. What distances did > you test? about 11km. did you test UDP (unidirectional) or TCP (bidirectional) throughput ? The larger slot time will increase the channel access overhead which should impact unidirectional throughput. With bidirectional traffic, the larger slottime should help to minimize collisions on loaded links. Overall this seems to increase the net throughput for us, especially in higher access categories (smaller backoff windows). Cheers, Mathias ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On 2012-10-30 2:00 PM, Mathias Kretschmer wrote: > On 10/30/2012 01:43 PM, Felix Fietkau wrote: >> On 2012-10-30 1:07 PM, Simon Wunderlich wrote: >>> From: Mathias Kretschmer >>> >>> According to 802.11-2007 17.3.8.6 (slot time), the slot time should >>> be increased by 3 us * coverage class. The code only increased the >>> ack timeout, which is fixed by this patch. >>> >>> We have noticed in our long shot scenario that we see less collisions >>> with this patch. >> At some point I had the slot time increase in the driver, but noticed a >> massive throughput degradation on 10-20 km links. Leaving the slot time >> alone and changing only the ACK timeout fixed this. What distances did >> you test? > > about 11km. did you test UDP (unidirectional) or TCP (bidirectional) > throughput ? I always use TCP, because UDP tests are too unrealistic to estimate real performance. > The larger slot time will increase the channel access overhead which should > impact > unidirectional throughput. > > With bidirectional traffic, the larger slottime should help to minimize > collisions > on loaded links. Overall this seems to increase the net throughput for us, > especially in higher access categories (smaller backoff windows). When I ran the test, the throughput degradation was so big that the links became almost useless. It was a long time ago, so maybe this was caused by another bug that has been fixed since. I will run another test with this patch in a current version... - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
On 2012-10-30 1:07 PM, Simon Wunderlich wrote: > From: Mathias Kretschmer > > According to 802.11-2007 17.3.8.6 (slot time), the slot time should > be increased by 3 us * coverage class. The code only increased the > ack timeout, which is fixed by this patch. > > We have noticed in our long shot scenario that we see less collisions > with this patch. At some point I had the slot time increase in the driver, but noticed a massive throughput degradation on 10-20 km links. Leaving the slot time alone and changing only the ACK timeout fixed this. What distances did you test? - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too
From: Mathias Kretschmer According to 802.11-2007 17.3.8.6 (slot time), the slot time should be increased by 3 us * coverage class. The code only increased the ack timeout, which is fixed by this patch. We have noticed in our long shot scenario that we see less collisions with this patch. Signed-off-by: Mathias Kretschmer [add standard reference and commit message] Signed-off-by: Simon Wunderlich --- drivers/net/wireless/ath/ath9k/hw.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 71cd9f0..1a3d483 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1114,7 +1114,8 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah) } /* As defined by IEEE 802.11-2007 17.3.8.6 */ - acktimeout = slottime + sifstime + 3 * ah->coverage_class + ack_offset; + slottime += 3 * ah->coverage_class; + acktimeout = slottime + sifstime + ack_offset; ctstimeout = acktimeout; /* -- 1.7.10 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel