From: Felix Fietkau <nbd@openwrt.org>
To: Benoit PAPILLAULT <benoit.papillault@free.fr>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
Derek Smithies <derek@indranet.co.nz>,
ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, wally@theblackmoor.net,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945
Date: Mon, 24 Nov 2008 10:43:15 +0100 [thread overview]
Message-ID: <492A7733.2000205@openwrt.org> (raw)
In-Reply-To: <492A5913.3070007@free.fr>
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.
- Felix
next prev parent reply other threads:[~2008-11-24 9:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 20:28 Unusually low speeds with ath5k and iwl3945 Maxim Levitsky
2008-11-22 0:52 ` Bob Copeland
2008-11-22 3:46 ` [ath5k-devel] " Derek Smithies
2008-11-22 12:33 ` Maxim Levitsky
2008-11-24 7:34 ` Benoit PAPILLAULT
2008-11-24 9:43 ` Felix Fietkau [this message]
2008-11-24 10:34 ` Johannes Berg
2008-11-25 19:46 ` Benoit PAPILLAULT
2008-11-25 22:47 ` Felix Fietkau
2008-11-22 10:16 ` [ipw3945-devel] " Rafał Miłecki
2008-12-03 16:55 ` reinette chatre
2008-12-03 17:09 ` Maxim Levitsky
2008-12-03 17:36 ` reinette chatre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492A7733.2000205@openwrt.org \
--to=nbd@openwrt.org \
--cc=ath5k-devel@lists.ath5k.org \
--cc=benoit.papillault@free.fr \
--cc=derek@indranet.co.nz \
--cc=ipw3945-devel@lists.sourceforge.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=wally@theblackmoor.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).