RE: d80211-drivers pull request (week-48)
Devicescape does understant that the hardware can do retries - but it adds software retries on top. This allows higher reliability, as well as correct handling of the powersave state machine. (PS bit from a STA is supposed to stop APs transmission immediately). Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Tuesday, December 12, 2006 1:35 AM To: Daniel Drake Cc: Michael Wu; John Linville; netdev@vger.kernel.org; Ulrich Kunitz Subject: Re: d80211-drivers pull request (week-48) On Tuesday 12 December 2006 02:07, Daniel Drake wrote: Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? What does devicescape do in response to not getting an ack? It does ratecontrol based on that. Basically: No ACK == failed packet. If too many failures, lower the rate. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 02:07, Daniel Drake wrote: Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? What does devicescape do in response to not getting an ack? It does ratecontrol based on that. Basically: No ACK == failed packet. If too many failures, lower the rate. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote: Just two observations: 1) The retry-failed-interrupt message contains the destination MAC address of the transmitted message. Hm, that might be useful to check in master or adhoc mode to make sure the tx queue isn't messed up. 2) We could get easily two acks for the same transmission. How would this occur? 3) We could get ACKs or retry-failed-interrupts for packets, for which no status has been requested by the upper layers. We report status for every frame which will get an ACK, which is every unicast frame. Coincidentally, d80211 uses the same logic to determine when it wants the status to be reported (IIRC). I suggest that the skbs as buffer for the URB transmissions. Yes, copying the entire frame to another buffer isn't very performance friendly. This was one of the things that bothered me when I ported zd1211rw. We could add a timeout value to each packet to make sure, that we don't ACK or NAK packets, which have been overdue. Some sort of watchdog to kick things when things stall could be useful, though I'm not sure how to go about it. -Michael Wu pgpHi8ZnfpgQg.pgp Description: PGP signature
Re: d80211-drivers pull request (week-48)
On Monday 11 December 2006 20:07, Daniel Drake wrote: Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? All 802.11 devices have to be able to handle retries in hardware to do random backoff properly. Still, the stack wants to know what happened. I think I remember reading that devicescape uses failed transmission rate in the rate adjustment calculations. Even without this racy ack system we can still achieve that - the device tells us every time it retries a transmit, and then it sends a special interrupt at the end saying that all retries failed. Yes, but it also uses successful transmissions in rate adjustment. I don't think this race is such a big deal. It will only happen when someone is really trying to mess with the link, and would cause the rate control to jump to the highest speed. However, if someone is really trying to mess with the link this way, the stability of the link is in trouble anyways. Wait for stations to send frames, and send an ack for every unicast frame - everyone will get confused. To actually mess with this code, the attacker would have to transmit acks nearly continuously as it can't tell exactly when is a good time to screw things up, and the driver recovers as soon as the queue is emptied. Someone transmitting all the time is a problem for all wireless cards. :) -Michael Wu pgpqy0LQcl1DB.pgp Description: PGP signature
Re: d80211-drivers pull request (week-48)
Michael Wu wrote: I don't think this race is such a big deal. It will only happen when someone is really trying to mess with the link, and would cause the rate control to jump to the highest speed. However, if someone is really trying to mess with the link this way, the stability of the link is in trouble anyways. Wait for stations to send frames, and send an ack for every unicast frame - everyone will get confused. To actually mess with this code, the attacker would have to transmit acks nearly continuously as it can't tell exactly when is a good time to screw things up, and the driver recovers as soon as the queue is emptied. Someone transmitting all the time is a problem for all wireless cards. :) It's ugly, in my mind not necessary, and it will kill performance. We haven't had to make such compromises in a long time. We got a large TX speed boost when the driver was modified to queue up multiple transmit URBs (i.e. don't wait for URB completion of the first) at the same time early during driver development. And even with that we're still a fair distance from the performance of the vendor driver. While the stack isn't so well suited for this device I'd much prefer to see a more simplistic workaround. For example, assume all packets were successful but then report a failure when an interrupt comes in. Or, if the stack won't accept out-of-the-blue notifications like that, then maintain a counter which is incremented when a failure is reported, and when transmitting the next few frames report them as failed and decrement the counter (while counter 0). Maybe disable rate control until we can come up with a nicer solution. Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211-drivers pull request (week-48)
On Monday 11 December 2006 22:51, Daniel Drake wrote: It's ugly, in my mind not necessary, and it will kill performance. We haven't had to make such compromises in a long time. We got a large TX speed boost when the driver was modified to queue up multiple transmit URBs (i.e. don't wait for URB completion of the first) at the same time early during driver development. And even with that we're still a fair distance from the performance of the vendor driver. Yes, synchronous anything tends to kill performance. I do not see what about this patch kills performance, however. It merely frees skbs at a later point. The additional code in the RX path should be negligible. Also, every other d80211 driver has some sort of similar mechanism, the only difference being that the one for zd1211rw-d80211 isn't as reliable. I do not think it is that ugly. While the stack isn't so well suited for this device I'd much prefer to see a more simplistic workaround. For example, assume all packets were successful but then report a failure when an interrupt comes in. Or, if the stack won't accept out-of-the-blue notifications like that, then maintain a counter which is incremented when a failure is reported, and when transmitting the next few frames report them as failed and decrement the counter (while counter 0). I don't think these solutions are much prettier than a tx_queue. Maybe disable rate control until we can come up with a nicer solution. I don't think that's gonna happen unless changes are made in the firmware, or there's some bit somewhere to flip that does exactly what we need. And surely, having some working rate control is better than requiring manual tx rate tuning, right? (which isn't an option in d80211 anyway) -Michael Wu pgpAau91AjvBt.pgp Description: PGP signature
Re: d80211-drivers pull request (week-48)
Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? What does devicescape do in response to not getting an ack? Does it retransmit? If that is all then it doesn't need to be at stack level, since the hardware handles that on its own, and we can configure that to behave the same way as the stack would. I think I remember reading that devicescape uses failed transmission rate in the rate adjustment calculations. Even without this racy ack system we can still achieve that - the device tells us every time it retries a transmit, and then it sends a special interrupt at the end saying that all retries failed. Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
