2008-09-15 03:20:51

by Brian Prodoehl

[permalink] [raw]
Subject: ath5k, higher bitrates (>24M) not working in IBSS mode

I'm testing the driver (2008-09-12 compat-wireless-old snapshot) doing
point to point communication in ad-hoc mode with some XR2's (AR5414)
on an ixp425 platform running kernel 2.6.25.1. "iwlist scanning"
reports RSSI around -30dBm. I'm setting the bitrate with iwconfig,
and all rates from 1M to 24M work beautifully, but if I set the rate
to 36M, 48M or 54M, absolutely no data gets through at those rates.
Its not like it gets really lossy or anything, absolutely nothing
(except broadcasts) get through.

It seems reminiscent of this thread:
http://kerneltrap.org/mailarchive/linux-ath5k-devel/2007/11/2/380573

Does anyone have these rates working with ath5k in ad-hoc mode?


2008-09-15 10:02:09

by Nick Kossifidis

[permalink] [raw]
Subject: Re: ath5k, higher bitrates (>24M) not working in IBSS mode

2008/9/15 Brian Prodoehl <[email protected]>:
> I'm testing the driver (2008-09-12 compat-wireless-old snapshot) doing
> point to point communication in ad-hoc mode with some XR2's (AR5414)
> on an ixp425 platform running kernel 2.6.25.1. "iwlist scanning"
> reports RSSI around -30dBm. I'm setting the bitrate with iwconfig,
> and all rates from 1M to 24M work beautifully, but if I set the rate
> to 36M, 48M or 54M, absolutely no data gets through at those rates.
> Its not like it gets really lossy or anything, absolutely nothing
> (except broadcasts) get through.
>

It's a known problem, not only for IBSS mode. We don't initialize RF
parts correctly, we are not doing any power calibration nor adaptive
noise immunity (ANI). Depending on your environment and your card you
might not be able to set any rate above 18M or you might get 25 -
27Mbits @ 54Mbits (i have seen both behaviours during my tests).

Right now this is work in progress, i hope we 'll have something soon
(at least for ANI). Broadcasts might get through because they don't
need to be ACKed from the card (to mark a frame as txed card must sent
the frame and receive an ack for it, if the noack flag is set then it
only has to send it and doesn't wait for an ack, so if rx path has
problems on some rates -due to bad rf initailization- card might be
able to send a frame but unable to receive the ack, so you get packet
loss for non-multicast frames).


--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick