We are finding that under certain scenarios, various WiFi cards
(Atheros, Intel, ...) fail to decode incoming packets for certain
periods of time on the order of 5->20ms. We are trying to enable a
low-latency wireless link in which losses during this window break our
requirement. A retransmission would essentially be too late.
During this period, we are trying to determine the reason for loss.
Whether it is fading, improper tuning of AGC, failure to account for
frequency offset, etc. Ideally, what we would like to know is whether
the card *tried* to acquire the carrier and if so, where it failed. I
have noticed several Atheros kernel debug counters which show things
such as a PHY error, but it's not clear at what stage it failed.
Are there any firmwares or drivers paired with off the shelf 802.11
cards which would be good for trying to debug this?
Thanks!
George
On 22 October 2011 05:09, George Nychis <[email protected]> wrote:
> We are finding that under certain scenarios, various WiFi cards
> (Atheros, Intel, ...) fail to decode incoming packets for certain
> periods of time on the order of 5->20ms. We are trying to enable a
> low-latency wireless link in which losses during this window break our
> requirement. A retransmission would essentially be too late.
>
> During this period, we are trying to determine the reason for loss.
> Whether it is fading, improper tuning of AGC, failure to account for
> frequency offset, etc. Ideally, what we would like to know is whether
> the card *tried* to acquire the carrier and if so, where it failed. I
> have noticed several Atheros kernel debug counters which show things
> such as a PHY error, but it's not clear at what stage it failed.
If you're not doing stupidly-high RX throughput, you could enable PHY
errors on the Atheros NICs instead of Just relying on the counters.
That way you can get reason values for the failed RX frames.
It may not be the -exact- reason (having the AGC get upset at you for
20ms? That seems a bit unlikely, considering how quick it needs to
adjust at the beginning of every RX'ed signal that may be a data
frame..) but it could be something like ANI interfering with RX.
There's been at least one reproducable report of that occuring w/
ath9k + AR5416 however I've not seen it happen on my FreeBSD/Linux
setups. For atheros, it could also be the periodic calibration code
kicking in.
I'd start by enabling PHY errors and watching the values of counters
whenever the error condition occurs. Under FreeBSD the 'athstats' tool
(and all the data exported by the HAL and driver) has allowed me to
leverage some basic correlational techniques to find/fix issues. You
may be able to do the same with a bit of hackery and the debugfs
export of these counters with ath5k/ath9k.
I think you can also enable receiving frames which fail the CRC check.
I forget if that is enabled by default.
Adrian