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

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

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