ath9k: apply coverage class on slottime too

PATCH New Simon Wunderlich 4 participants 10 messages Oct 30, 2012 – Apr 22, 2013 Qualcomm Atheros ATH9K wireless driver

lore

Share & tools

lore

Simon Wunderlich

author

2012-10-30 12:07 UTC #0 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

From: Mathias Kretschmer <[email protected]>

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 <[email protected]>

[add standard reference and commit message]

Signed-off-by Simon Wunderlich <[email protected]>

---
 drivers/net/wireless/ath/ath9k/hw.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/net/wireless/ath/ath9k/hw.c +2 -1

index 71cd9f0..1a3d483 100644
@@ -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;
 
 	/*

Signature · 1 line

1.7.10

Felix Fietkau

2012-10-30 12:43 UTC #1 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 8 lines · Simon Wunderlich

From: Mathias Kretschmer <[email protected]>
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

Mathias Kretschmer

2012-10-30 13:00 UTC #2 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 7 lines · Felix Fietkau

Quoted 6 lines · Simon Wunderlich
From: Mathias Kretschmer <[email protected]>
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.

Quoted 6 lines

Quoted 2 lines
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

Felix Fietkau

2012-10-30 13:24 UTC #3 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 8 lines · Mathias Kretschmer

Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Simon Wunderlich
From: Mathias Kretschmer <[email protected]>
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.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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.

Quoted 6 lines

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

Mathias Kretschmer

2012-10-31 10:47 UTC #4 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 11 lines · Felix Fietkau

Quoted 10 lines · Mathias Kretschmer
Quoted 9 lines · Felix Fietkau
Quoted 8 lines · Simon Wunderlich
From: Mathias Kretschmer <[email protected]>
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.

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
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.

Quoted 10 lines

Quoted 6 lines
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

Quoted 2 lines

- Felix

Simon Wunderlich

author

2012-11-28 12:06 UTC #5 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

In reply to Felix Fietkau

Quoted 6 lines · Felix Fietkau

[...]
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20121128/a3c8bd88/attachment.pgp

Mathias Kretschmer

2012-12-07 12:35 UTC #6 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

In reply to Felix Fietkau

Hi all,

Quoted 7 lines · Felix Fietkau

Quoted 6 lines · Simon Wunderlich
From: Mathias Kretschmer <[email protected]>
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.

Quoted 9 lines

Quoted 2 lines
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

Simon Wunderlich

author

2013-04-22 10:08 UTC #7 lore raw

PATCH 1/1 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

Quoted 91 lines · Mathias Kretschmer

Hi all,
Quoted 7 lines · Felix Fietkau
Quoted 6 lines · Simon Wunderlich
From: Mathias Kretschmer <[email protected]>
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.
Quoted 9 lines
Quoted 2 lines
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

Quoted 12 lines

794,2347
795,796
832,420
833,1800
834,891
975,315
1014,329
1015,257

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130422/751b6ee9/attachment.pgp

Felix Fietkau

2013-04-22 10:15 UTC #8 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 5 lines · Simon Wunderlich

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

John W. Linville

2013-04-22 18:38 UTC #9 lore raw

PATCH 1/1 ath9k: apply coverage class on slottime too

Quoted 7 lines · Felix Fietkau

Quoted 5 lines · Simon Wunderlich
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?

Signature · 2 lines

John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.