On Friday 19 September 2008, Mattias Nissler wrote: > On Fri, 2008-09-19 at 12:08 +0300, Mikko Virkkilä wrote: > > On Thu, 2008-09-18 at 22:29 +0000, Mattias Nissler wrote: > > > [I've added the zd1211rw maintainers to the CC, I hope they can shed > > > some light on the question whether the ack queue mechanism that driver > > > has is actually correct] > > > > > > I've had a closer look at the idea of deciding whether a frame has > > > been > > > transmitted succesfully by monitoring incoming ACK frames and I've hit > > > a > > > fundamental problem: How do you correlate incoming ACK frames to the > > > frames that were actually transmitted? The ACK frame only carries the > > > address of the station that transmitted the frame being acked, no > > > further information. Now this means if you have the hardware TX two > > > frames and receive one ACK frame in the RX path, you cannot know which > > > TX frame the ACK belongs to, because they will be identical, right? > > > > > > The hardware, however, knows, because the ACKs are required to be > > > transmitted directly after the corresponding frame is received, but we > > > don't know in the driver about this timing information, at least not for > > > rt2x00. > > > > > > I wonder whether the ack queue idea Mikko found in the zd1211rw driver > > > is actually working correctly for that driver? I've only had a short > > > look, but found that incoming ACKs are only matched against transmitted > > > frames by means of the address carried within the ACK. So I'd think in > > > the situation I outlined above, the zd1211rw driver will also be unable > > > to match the ACK to the correct frame. Any comments on this? > > > > > > Mattiass > > > > > > > AFAIK your analysis is correct and I think this is somewhat of a known > > problem with the implementation in zd1211rw driver. I haven't come > > across a way of getting around the problem. I read some suggestions > > about stopping all transmission to a certain address until we get a > > status update for the previous packet sent to that address, but iirc > > this was deemed impractical. On the other hand the current > > implementation in zd1211rw (and hopefully soon in rt2x00) doesn't really > > break anything that works without it and on rt2x00 it gets AP-mode in a > > somewhat more usable state. > > Well, as long as nothing vitally depends on the transmissions status > (i.e. MAC layer acknowledgements in 802.11 lingo), you are right that it > won't break anything. Nevertheless, it is code that is known to be > working incorrectly and non-fixable, so I'd vote against it (I'd rather > live with the approach of always reporting successful tx status as you > have proposed earlier if I had to choose from the two of them). Maybe we > just have to accept that there is hardware that cannot report MAC layer > acknowledgements back to the driver. Unless somebody comes up with a > feasible idea how to do it. Ivo, do we have a contact at Ralink to ask > about this? The Legacy USB drivers don't care about the TX status, if it wants to know the TX statistics it reads the register which contains the ACK/RTS counters and determine with those values if the link is good or not. Seeing that the PCI drivers also don't really care about the TX status (other then setting some statistics) I think we can assume the TX status isn't important for the Ralink people. But I'll send a mail to Ralink to see if they actually do have some ideas about it. > This brings up the question whether we can do without tx status > reporting. Does anyone know why hostapd requires the tx status? As far > as I understand, mac80211 only uses the tx status reporting only for the > tx rate control. Rate control algos that don't use tx status are > definitely feasible (and in fact we'll need one for rt73). > > I'll look into hostapd to figure out whether the tx status reporting is > really required when I find some time. However, I've just received > rt2800 hardware, so getting the rt2800 driver going is my top priority > for the next weeks. Ivo -- 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
