On Wed, Jul 14, 2010 at 05:51, Ivo Van Doorn <ivdoorn@xxxxxxxxx> wrote: > On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa > <helmut.schaa@xxxxxxxxxxxxxx> wrote: >> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn: >>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa >>> <helmut.schaa@xxxxxxxxxxxxxx> wrote: >>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn: >>> >> I am currently looking into the old problem of the mac80211 rate >>> >> control algorithms >>> >> and USB devices. The Ralink USB devices (and as far as I know, the >>> >> other USB devices >>> >> as well), do not work well with the PID and Minstrel algorithms. This >>> >> is caused by the >>> >> fact that USB devices do not report the TX status to mac80211. >>> > >>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO >>> > register like the PCI variants? Does it contain useful data or just crap? >>> >>> Well I guess he has the registers (we don't have rt2870 specific specsheets, >>> but the register definitions from the original Ralink driver to >>> suggest the register >>> is there). However, even if it contains valid data, how do you want to match >>> the contents of that register with the sent frames in the queue? >> >> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should >> contain the same ID alongside the TX status after the frame was processed >> by the hw. > > True, but we would have the same problem in rt2800pci, that the number > of bits is too limited to completely identify a queue + queue index correctly. We could have a table that matches queue and queue index to the packet's ID. So if we're sending packet #47 from queue #1, and it gets assigned id #9, then we drop that information into the table - so when the hardware tells us the status of packet id #9 we can look up which queue it is and send it to the right place. Of course, this means storing a stack of extra data in system memory, as well as having the complexity of looking up the queue data when we get the status back, but if we've only got limited bits, then that'll set a hard limit on the amount of data and time to retrieve, and we may not even need all of it unless the hardware's running at full capacity. We could reduce it further if we don't need a status of *every* packet - we could potentially get away with only storing data for, let's say, every fourth packet or something. As we're likely to see similarly crippled devices elsewhere, maybe we could incorporate this type of accounting into mac80211 somewhere. Of course, this could just be a huge stack of overhead for a problem that could be solved much more elegantly, but yeah. *hands over $0.02* Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx .Plan: http://sites.google.com/site/juliancalaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
