On Wed, 2014-05-07 at 13:43 +0200, Michal Kazior wrote: > We can't really guarantee how long we'll need to stop beaconing for. > > Assume: AP+STA. Start AP CSA bcn_int=100ms, cs_count=5. While CSA > progresses STA receives cs_count=100 (with bcn_int=100ms). > > This is all theory and in practice you won't get cs_count that big and > the lag greater shouldn't be greater than 5 or 6 beacon intervals. Is > that an "extended" period of time? I don't know. Should we even worry > about this? I don't think so. I'm not sure why we'd even allow this to start with though. We should be able to sync it to 1 beacon interval, it seems? Particularly if we start the switches together. > > Multi-BSS I totally see, but if you're trying to do that with different > > beacon intervals you're probably in a world of pain already - not sure > > we should support that to start with... > > You still can have different TBTTs across your AP vifs. ath10k does > this, although it should be possible to force it to beacon in bursts. True, but then you'd still technically have a single point where the switch can happen, without missing a beat (beacon) > > AP/GO-follows-STA I can also see, due to regulatory and concurrent > > BSS/P2P usage. > > > > As for those other cases, are they really relevant? > > I think I lost track of the point of the discussion at some point :-) > Weren't we discussing csa_active? :) johannes -- 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
