[snip all the things] Ok, so ath5k is doing better with regards to interrupt handling and processing it seems. So next I would look at the TX and RX descriptor contents and timing. I think you'll need to add tracing to ath5k.
I'd trace: * interrupts coming in * the timestamp of each RX'ed frame * the timestamp of each TX queued frame * the timestamp of each TX completed frame There are a few things that may be different in your setup that are worth investigating: * ath5k may not be queuing as many frames to the hardware at once. Madwifi would just keep the transmit hardware queue totally full of tx buffers, rather than only putting a small handful of frames to the hardware and leaving the rest queued in software. Any extra processing latency will thus kill you. * You should see if the WME parameters are setup. madwifi was doing 802.11e bursting - once you won TxOP, the TXQ was configured to let you burst frames with minimal (or no) cwin checking; * .. and the WME parameters for actual queue WME parameters may not be setup, so the default Cwmin/Cwmax parameters and no burst window may be configured, leading to poor performance; * Maybe it could also be related to not supporting fast-frames? Check to see if madwifi and your peer device are doing ff for some reason. There's lots of things to debug at the MAC layer before worrying about things at the PHY/radio layer. Good luck! -adrian
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
