linux-kernel - Re: [PATCH v7 3/3] nl80211/mac80211: Report signal average

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201011191749.31974.br1@einfach.org>
Date:	Fri, 19 Nov 2010 17:49:31 +0900
From:	Bruno Randolf <br1@...fach.org>
To:	Bob Copeland <me@...copeland.com>
Cc:	Johannes Berg <johannes@...solutions.net>, Jouni Malinen <j@...fi>,
	linville@...driver.com, randy.dunlap@...cle.com,
	peterz@...radead.org, blp@...stanford.edu,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	Lars_Ericsson@...ia.com, stefanr@...6.in-berlin.de,
	kosaki.motohiro@...fujitsu.com, akpm@...ux-foundation.org,
	kevin.granade@...il.com
Subject: Re: [PATCH v7 3/3] nl80211/mac80211: Report signal average

On Thu November 18 2010 08:11:18 Bob Copeland wrote:
> On Wed, Nov 17, 2010 at 11:16 AM, Johannes Berg
> <johannes@...solutions.net> wrote:
> > On Wed, 2010-11-17 at 17:28 +0900, Bruno Randolf wrote:
> >> I understand that this could be more efficient, but if it matters or not
> >> - honestly, I don't know. Can a more knowledgeable person than me
> >> comment on this?
> > 
> > Yes, it does matter -- think of an embedded MIPS board running at 500MHz
> > and trying to push 11n speeds.

OK, I have done tests with a 266MHz x86 board, pushing 30Mbps UDP thru it. It 
can handle maximum around 18Mbps thuput in both cases, with and without the 
average. And that is using the ewma function two times (ath5k beacons and 
signal average). Here are the results of iperf -u -c IP -b 30M -t 120 (2min of 
30Mbps UDP):

With average:

0.0-120.4 sec    269 MBytes  18.7 Mbits/sec  0.370 ms 114323/306094 (37%)
0.0-120.4 sec    263 MBytes  18.3 Mbits/sec  0.336 ms 118668/306110 (39%)
0.0-120.4 sec    265 MBytes  18.5 Mbits/sec  0.229 ms 117036/306120 (38%)

Without:

0.0-120.4 sec    267 MBytes  18.6 Mbits/sec  0.385 ms 115457/306123 (38%)
0.0-120.4 sec    267 MBytes  18.6 Mbits/sec  0.374 ms 115868/306063 (38%)
0.0-120.4 sec    261 MBytes  18.2 Mbits/sec  0.566 ms 119603/306112 (39%)

So I conclude that compared to all the other things we do when we receive a 
packet having one division more or less does not have a huge performance 
impact.

> I assume the number of samples (weight) is the more
> important tunable.  One option is you can require factor
> to be a power of two that is much larger than weight,
> then at least you can store factor/weight precomputed
> and multiply by it instead of doing a divide in ewma_add.
> Then ewma_get can also just be a shift as well.

That's a good idea! I will try to improve the code.

bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/