Christian Lamparter wrote: > 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. When is that PRETBTT signaled, on every beacon or only on DTIM beacons? If on the former, I do not see yet where the code filters for the latter. > > 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 don't think it's the right long-term solution to let such time-critical jobs be done by the host as long as the controller is capable of handling it more accurately. > >> 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. Likely. But maybe it also signals the that this period has started so that the controller can send out the corresponding frames. Otherwise it had to process every beacon interrupt to filter for DTIM. > > 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. > Ah, I see. > 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 ;-) Sounds interesting. Is it derived from ar9170-fw or written from scratch? In any case, I'm looking forward to those improvements. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
