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]
Date:	Mon, 24 Nov 2008 11:34:06 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Felix Fietkau <nbd@...nwrt.org>
Cc:	Benoit PAPILLAULT <benoit.papillault@...e.fr>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Derek Smithies <derek@...ranet.co.nz>,
	ath5k-devel@...ts.ath5k.org, linux-wireless@...r.kernel.org,
	linux-kernel@...r.kernel.org, ipw3945-devel@...ts.sourceforge.net,
	wally@...blackmoor.net
Subject: Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945

On Mon, 2008-11-24 at 10:43 +0100, Felix Fietkau wrote:
> Benoit PAPILLAULT wrote:
> > I did a similar test here and results is very strange. AP was my good
> > old linksys WRT54G running an iperf server. Client was a laptop running
> > either ath5k or madwifi/trunk and an iperf client. Channel is 5. Both
> > drivers show the same behaviour.
> > 
> > At the beginning, throughput was very low : 500 - 600 kbit/s. Suddenly
> > (after few minutes), it jumps to 15 - 17 Mbit/s and then few minutes
> > later (let's say 10 - 20 minutes maybe), it jumps back to 500 - 600
> > kbit/s. Using a fixed rate has no effect.
> > 
> > I used my latest wireless monitoring tools and I did not saw lost of
> > duplicates or lost packets. The only difference was the number of
> > packets sent by seconds....
> > 
> > Looking a my syslog, I just saw few messages, unrelated in time with the
> > throughput going up or down. They were:
> > - ath5k : unsupported jumbo
> > - switching to short barker preamble
> > - switching to long barker preamble
> > 
> > I can repeat the same test with iwl3945 as well, if needed.
> While reading the code for calculating the frame duration, i noticed
> something odd: It doesn't seem to be taking into account the short
> vs long preamble distinction for ERP rates. IMHO this might be causing
> issues like this. I've seen similar behaviour a long time ago when testing
> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
> 600 kbits/s).
> When I analyzed the problem with an extra monitor mode card, I found out
> that the throughput drop is caused by a huge number of retransmissions,
> and if I remember correctly (I didn't look for this specifically back then),
> the retransmissions went down the rate scaling table until they hit the
> first non-ERP rate and that one worked on the first try.
> 
> Johannes, does that sound like a probable cause? If so, it should be easy
> to fix.

I have no idea. Shouldn't that be easy to tell from the monitor? And if
the short/long switching was _unrelated_ in time it seems like it
wouldn't be a problem?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ