[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


Hi,

> 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
switch.

Ivo



More information about the users mailing list