[rt2x00-users] [PATCH RFC] rt2800usb: TX_STA_FIFO read timer
Ivo Van Doorn
ivdoorn at gmail.com
Tue Jan 11 03:40:46 EST 2011
> On Mon, Jan 10, 2011 at 05:00:09PM +0100, Helmut Schaa wrote:
>> Am Montag, 10. Januar 2011 schrieb Johannes Stezenbach:
>> > as discussed some time ago my previous patch
>> > "rt2800usb: read TX_STA_FIFO asynchronously"
>> > (in rt2x00/experimental) makes it more likely
>> > for TX_STA_FIFO entries to be stuck in the FIFO until
>> > the watchdog picks them up, because the TX_STA_FIFO read
>> > is now happening quicker after TX DMA is done.
>> Nice. Did you do any performance measurements again?
> Not yet, I'm still testing with debug output
> until I have confirmed it works correctly. I just
> hit an endless loop of
> [19608.093097] rt2800usb_tx_sta_fifo_timeout
> [19608.097467] rt2800usb_tx_sta_fifo_read_completed: pending
> [19608.103107] rt2800usb_tx_sta_fifo_timeout
> [19608.107473] rt2800usb_tx_sta_fifo_read_completed: pending
> so I guess I have to catch the case when a TX status
> FIFO entry is lost (rt2800usb_txstatus_pending() will
> always return true). And this reminded me that the
> watchdog does not catch this case anymore
> because rt2800_txdone() won't do anything when
> the txstatus_fifo is empty...
>> > In theory it shouldn't take that long to send a packet but the
>> > debug output suggests otherwise so I picked 10ms for the timeout.
>> > I guess there is a lot of traffic from other APs in the neighbourhood
>> > on the same channel.
>> It can easily take >= 10ms, depending on the channel utilization and,
>> number of retries etc.
>> IMHO 10ms is a safe value.
> OK, thanks.
I'm a bit worried about the complexity which is being added.
So far this patch will start allocating and freeing objects for
each frame which has been send (in the register_read_async),
apply timers and all kind of logics to read the registers.
However, I still can't see what we are fixing here, nor do I see
any improvements in the link quality or my association stresstest.
As far as I can see, most problems are currently caused by the
usage of workqueues itself and the way we flush() before a channel
More information about the users