[PATCH] ath9k: apply coverage class on slottime too

[PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

From: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>

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 <mathias.kretschmer@fokus.fraunhofer.de>
[add standard reference and commit message]
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
 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

Re: [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
> From: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
> 
> 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

Re: [PATCH] ath9k: apply coverage class on slottime too

[Mathias Kretschmer]

On 10/30/2012 01:43 PM, Felix Fietkau wrote:
> On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
>> From: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
>>
>> 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

Re: [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

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 <mathias.kretschmer@fokus.fraunhofer.de>
>>>
>>> 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

Re: [PATCH] ath9k: apply coverage class on slottime too

[Mathias Kretschmer]

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 <mathias.kretschmer@fokus.fraunhofer.de>
>>>>
>>>> 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
>

Re: [PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] ath9k: apply coverage class on slottime too

[Mathias Kretschmer]

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 <mathias.kretschmer@fokus.fraunhofer.de>
>>
>> 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

Re: [PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

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 <mathias.kretschmer@fokus.fraunhofer.de>
> >>
> >>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
> 
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] ath9k: apply coverage class on slottime too

[Felix Fietkau]

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

Re: [PATCH] ath9k: apply coverage class on slottime too

[John W. Linville]

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. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.