On Sunday 06 December 2009 19:23:09 Jan Kiszka wrote: > Christian Lamparter wrote: > > This patch should fix "broadcast traffic before DTIM beacon", > > But there is a downside: the broadcast (e.g arp) frames > > might get delayed and won't make it in time. > > > > let me know, if this patch does any good, or not... > > Mmm, how is this supposed to work? The driver sets the PRETBTT interval and the HW will trigger the PRETBTT event. Which will tell the driver to update the beacon, which _in turn_ triggers the BCN_CFG event and the buffered BC frames are _released_ into the queues. Now the problem is that under traffic the BC/MC frames might be delayed in the tx_pending queues and don't make it in time. > I still haven't started hacking on this as well, but I read a bit > about DTIM. > One thing I think to have understood is that the DTIM interval is typically > larger than the beacon interval. There is even some interrupt on ar9170 > indicating this event, it's just not enabled yet. Na, I _think_ that BIT is meant for the PS/station mode and is used to say to the fw/driver to stay alert for incoming broadcast/multicast data. If this really is the case, then I'm afraid to say: the bit is probably for little use in this situation. > Moreover, I do not yet understand how deferring multicast frames works > in this patch. How are they filtered out from normal frames and queued > until the beacon event? (But that misunderstanding might be due to the > fact that I haven't read the whole driver code yet.) ar9170 does not have a "Content After Beacon" queue like p54 or ath5k/ath9k. But luckily the mac80211 stack provides the necessary queuing mechanism. And all the driver needs to do: - set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING - grab the buffered BC/MC frames and push them to the device. Note: That's the current situation. But maybe you'll be in for a big surprise. There is a special firmware & driver: "carl9170", which will add several useful features: * accurate tx status feedback * _CAB_ queuing in firmware => this should be enough to finally enable NL80211_IFTYPE_AP / MESH. * multirate retry support (minstrel) => improve performance in suboptimal environments. * Real Hardware QoS support. (But unfortunately with a catch) I hope it will be ready for Christmas ;-) Regards, Chr -- 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
