Hello everybody,
I have been following the ath5k project for a while hoping that the
new driver could sort out the speed issue that afflicts the MIPS
platform I am using: I'm involved in a performance evaluation task
and I need to hack the kernel in such a way that frames are created
from a task running in kernel space and sent directly to the device
without passing through the traditional network stack. Clearly I
cannot deal with a closed binary.
After a small effort to have 2.6.24-rc2 booting up and running
without problems on my MIPS boards (Mikrotik RB133), I finally added
the ath5k driver and everything went fine: the driver is usable also
on these MIPS boards, wlan0 network is up and everything work, I can
join a test network without using encryption, still have not tested
with WEP.
I did some tests and I see that setting up filters properly I can
also see ACKs, RTSs and all other stuff.
I have now a few questions
- is it possible to (e.g. does anybody ever succeeded to) ask the hw
to transmit a skb-encoded frame with arbitrary content? I mean, is it
possible to disable CSMA/CA mechanism, call ath5k_txbuf_setup() and
let the hw to not check if a frame is actually received by someone?
- how is it implemented the rate control in the ath5k driver? I see
that if a force 54M rate and the channel does not allow (e.g. noise
due to other BSs in the same channel) this rate the driver takes a
long time to switch to a lower rate (and usually it switches to 1Mb/s)
- I'm not using the wireless git branch but the standard development
2.6.24-rc2 code with ath5k added in driver/net/wireless: I suppose
that this is ok because I have no problems with the net/mac80211 part
coming with the standard kernel but if someone is aware of changes in
this part, please let me now.
I would like also to report that I did a very simple test connecting
a couple of Atheros card with a coaxial cable (impedances adapted and
both systems are connected to the same ground). The two PCs involved
are running x86 Linux 2.6.24-rc2 when using ath5k and Linux 2.6.23
when using standard Madwifi code. I see that independently of the
channel rate (from 1Mb/s to 54Mb/s) I always get better performances
with standard Madwifi code. Could this depend on how queues are
handled on the ath5k code?
Regards,
FG
%%%%%%%%%%%%%%%%%%%%%
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
%%%%%%%%%%%%%%%%%%%%%
On Nov 20, 2007 8:17 AM, Francesco Gringoli
<[email protected]> wrote:
> Hello everybody,
>
> I have been following the ath5k project for a while hoping that the
> new driver could sort out the speed issue that afflicts the MIPS
> platform I am using: I'm involved in a performance evaluation task
> and I need to hack the kernel in such a way that frames are created
> from a task running in kernel space and sent directly to the device
> without passing through the traditional network stack. Clearly I
> cannot deal with a closed binary.
>
> After a small effort to have 2.6.24-rc2 booting up and running
> without problems on my MIPS boards (Mikrotik RB133), I finally added
> the ath5k driver and everything went fine: the driver is usable also
> on these MIPS boards, wlan0 network is up and everything work, I can
> join a test network without using encryption, still have not tested
> with WEP.
Francesco, WEP doesn't work yet. I had issues with it at least when I
tested that code path. I've seen a few people reporting already issues
with it as if it did work. I shall patch this to let users know it
doesn't work -- we should let it through only if it works.
> I did some tests and I see that setting up filters properly I can
> also see ACKs, RTSs and all other stuff.
Thanks for reporting this. Glad to know its working.
> I have now a few questions
>
> - is it possible to (e.g. does anybody ever succeeded to) ask the hw
> to transmit a skb-encoded frame with arbitrary content? I mean, is it
> possible to disable CSMA/CA mechanism, call ath5k_txbuf_setup() and
> let the hw to not check if a frame is actually received by someone?
Should be possible, yes. I'd poke with this:
>From ath5k.h:
/* Register for RSSI threshold has a mask of 0xff, so 255 seems to
* be the max value. */
#define AR5K_TUNE_RSSI_THRES 129
/* This must be set when setting the RSSI threshold otherwise it can
* prevent a reset. If AR5K_RSSI_THR is read after writing to it
* the BMISS_THRES will be seen as 0, seems harware doesn't keep
* track of it. Max value depends on harware. For AR5210 this is just 7.
* For AR5211+ this seems to be up to 255. */
#define AR5K_TUNE_BMISS_THRES 7
>From reg.h:
/*
* RSSI threshold register
*/
#define AR5K_RSSI_THR 0x8018 /* Register Address */
#define AR5K_RSSI_THR_M 0x000000ff /* Mask for
RSSI threshold [5211+] */
#define AR5K_RSSI_THR_BMISS_5210 0x00000700 /* Mask for
Beacon Missed threshold [5210] */
#define AR5K_RSSI_THR_BMISS_5210_S 8
#define AR5K_RSSI_THR_BMISS_5211 0x0000ff00 /* Mask for
Beacon Missed threshold [5211+] */
#define AR5K_RSSI_THR_BMISS_5211_S 8
#define AR5K_RSSI_THR_BMISS (ah->ah_version == AR5K_AR5210 ? \
AR5K_RSSI_THR_BMISS_5210 :
AR5K_RSSI_THR_BMISS_5211)
#define AR5K_RSSI_THR_BMISS_S 8
But I haven't tested it myself yet. If I test or find something more
useful I'll let you know.
> - how is it implemented the rate control in the ath5k driver?
mac80211 drivers follow the rate control algorithms designed for
mac80211. So the right question is how is rate control implemented on
mac80211. For that please see net/mac80211/rc80211_simple.c. Its our
only algorithm so far. I'd be nice to get minstrel ported to mac80211.
I believe a few people have said they were going to try.
> I see
> that if a force 54M rate and the channel does not allow (e.g. noise
> due to other BSs in the same channel) this rate the driver takes a
> long time to switch to a lower rate (and usually it switches to 1Mb/s)
rc80211_simple.c starts off at the lowest rate on
rate_control_simple_rate_init() as a workaround for it not yet using
the RSSI from previous packets as 802.1x auth is required immediately
after association. Until that is not fixed we start off at 1Mbps.
Please note that as Nick pointed out we are still having issues with
higher rates. I'd only rely up to 11Mbps for now.
> - I'm not using the wireless git branch but the standard development
> 2.6.24-rc2 code with ath5k added in driver/net/wireless: I suppose
> that this is ok because I have no problems with the net/mac80211 part
> coming with the standard kernel but if someone is aware of changes in
> this part, please let me now.
With ath5k I'd try to stick to the latest as the driver is getting
patched heavily. I understand this is a pain specially if your machine
is slow. A possible workaround is to use the compatibility package
with your local git clone to pull updates from:
http://linuxwireless.org/en/users/Download
Although this intended for older kernels this also lets you keep
updating the sources from your local git tree so you can *just*
compile mac80211 and necessary mac80211 drivers out-of-kernel. You can
change the git tree directory it expects in scripts/admin-update.sh,
on the GIT_TREE variable. By default it assumes you'll use:
/home/$USER/devel/wireless-2.6
This is what I do for slow machines right now instead of cross-compiling.
Luis
Hello,
(sorry if you already know, however) I was debugging the driver on my
mips board and I discovered a problem with the RTS/CTS procedure. I
see that even if I set the threshold for RTS, packets that are longer
than the threshold are correctly scheduled by net/mac80211 as to be
led by the RTS/CTS procedure (this means that timing is correctly
calculated to take into account the CTS that follows the RTS): this
is then correctly reported to the ath5k_tx() funtion inside the
control structure, but the driver actually misses to setup the
hardware to enter the RTS procedure.
For the sake of clarity, the issue affects also Intel code.
Regards,
FG
> I would like also to report that I did a very simple test connecting
> a couple of Atheros card with a coaxial cable (impedances adapted and
> both systems are connected to the same ground). The two PCs involved
> are running x86 Linux 2.6.24-rc2 when using ath5k and Linux 2.6.23
> when using standard Madwifi code. I see that independently of the
> channel rate (from 1Mb/s to 54Mb/s) I always get better performances
> with standard Madwifi code. Could this depend on how queues are
> handled on the ath5k code?
>
> Regards,
> FG
>
Not only queues but mostly tx power setting imho, we don't initialize
phy properly if we don't set tx power the right way. Madwifi/binary
hal knows how to propertly initialize phy so it has better performace
over ath5k. This is mostly seen in OFDM operation (a/g).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
Francesco Gringoli wrote:
> Hello everybody,
>
> I have now a few questions
>
> I would like also to report that I did a very simple test connecting a
> couple of Atheros card with a coaxial cable (impedances adapted and both
> systems are connected to the same ground). The two PCs involved are
> running x86 Linux 2.6.24-rc2 when using ath5k and Linux 2.6.23 when
> using standard Madwifi code. I see that independently of the channel
> rate (from 1Mb/s to 54Mb/s) I always get better performances with
> standard Madwifi code. Could this depend on how queues are handled on
> the ath5k code?
Madwifi may have some of their superg features on like fast frames, compression, turbo mode etc. http://www.super-g.com/ .
-Ack