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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <492C808A.20403@openwrt.org>
Date:	Tue, 25 Nov 2008 23:47:38 +0100
From:	Felix Fietkau <nbd@...nwrt.org>
To:	Benoit PAPILLAULT <benoit.papillault@...e.fr>
CC:	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, Johannes Berg <johannes@...solutions.net>
Subject: Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945

Benoit PAPILLAULT wrote:
> Felix Fietkau a écrit :
>> 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,
> 
> In the test I've done, there was no retransmission at all (no
> duplicates). I don't save a capture file, so I cannot tell for sure.
Which test specifically? iwl3945 or ath5k?
If ath5k doesn't show any retransmissions, the problem might not be
related. Please do make some logs of the throughput issue and then
some more of the same kind of traffic without throughput issues
(same card, same driver).

> What is the code computing frame duration you are referring to? How it
> could affect the hardware behavior?
I looked at it again and now I don't think it's the cause anymore. I
 did some comparisons against other stacks/drivers and this part
seems correct after all.

- Felix
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ