On Monday 07 December 2009 21:08:32 Kalle Valo wrote: > Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> writes: > > > 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 know what time constraints you refer to here, but clients > should stay awake until they have received a multicast/broadcast > message with the moredata bit disabled. So, in theory, it doesn't > matter even if the frames are transmitted even 20 ms after the beacon. > (In practise some hardware might have timers for this, I think at > least wl1251 had one.) > Of course the downside is the increased power consumption. But it's > still better than to not receive the multicast/broadcast frames at all :) That's the thing: 802.11-2007 11.2.1.5 f) says: "*Immediately* after every DTIM, the AP shall transmit all buffered broadcast/multicast MSDUs...". And I cannot rule out that some Devs took this quite literally. ;-) Anyway, here is a case that I've witnessed: During testing, I caught samples where MC/BC frames were delayed for more up to 115ms. (b_interval = 102.4ms and dtim_period = 3) and this is where another paragraph in 11.2.1.5 f) kicks in: "If the AP is unable to transmit all of the buffered broadcast/multicast MSDUs before the TBTT following the DTIM, the AP shall indicate that it will continue to deliver the broadcast/multicast MSDUs by setting the bit for AID 0 (zero) in the bit map control field of the TIM element of every Beacon frame, until all buffered broadcast/multicast frames have been transmitted." And if you look at the mac80211 code: ieee80211_beacon_add_tim, you can see why this is a problem: if (bss->dtim_count == 0 && !skb_queue_empty(&bss->ps_bc_buf)) aid0 = 1; The BC/MC bit is only set for DTIM beacons, but the MC/BC traffic _arrived_ 116ms after the DTIM beacon had aired and worse: even after the normal beacon, without the BC/MC flag... Note: * Unfortunately it is not unusual for ar9170 to *forget* tx_status reports and then we have to wait for the _janitor_ work to _retire_ old frames. * the beacon (delta) data is uploaded through the command interface and therefore the beacon is always right on time. 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
