Return-path: Received: from [217.64.175.212] ([217.64.175.212]:34587 "EHLO mx-relay12-muc.antispameurope.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S932866Ab2JaKsV (ORCPT ); Wed, 31 Oct 2012 06:48:21 -0400 Message-ID: <509101D9.2040209@fokus.fraunhofer.de> (sfid-20121031_114832_052702_79A5360C) Date: Wed, 31 Oct 2012 11:47:53 +0100 From: Mathias Kretschmer MIME-Version: 1.0 To: Felix Fietkau CC: Simon Wunderlich , , , , , , Simon Wunderlich Subject: Re: [PATCH] ath9k: apply coverage class on slottime too References: <1351598855-21427-1-git-send-email-siwu@hrz.tu-chemnitz.de> <508FCB77.9000303@openwrt.org> <508FCF5A.2080204@fokus.fraunhofer.de> <508FD505.4080404@openwrt.org> In-Reply-To: <508FD505.4080404@openwrt.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 >