On 2019-01-30 09:37, Stanislaw Gruszka wrote: > On Tue, Jan 29, 2019 at 01:40:57PM +0100, Lorenzo Bianconi wrote: >> > Felix Fietkau <nbd@xxxxxxxx> writes: >> > >> > > On 2019-01-29 13:07, Kalle Valo wrote: >> > >> Felix Fietkau <nbd@xxxxxxxx> writes: >> > >> >> > >>> On 2019-01-29 12:47, Kalle Valo wrote: >> > >>>> Stanislaw Gruszka <sgruszka@xxxxxxxxxx> writes: >> > >>>> >> > >>>>> We can configure beaconing, but without TBTT interrupt we >> > >>>>> can not support PS buffering. This can be added later using >> > >>>>> kernel hrtimer, if we can keep it in sycn with device timer. >> > >>>>> >> > >>>>> I tested AP and IBSS modes. >> > >>>> >> > >>>> So how does this work reliably so that there's no packet loss with >> > >>>> clients using power save? >> > >>> >> > >>> There will be multicast packet loss for clients using power save. >> > >> >> > >> Isn't that a problem? At least as a normal user I would very frustrated >> > >> if sometimes my connection work and sometimes not, for example if I'm >> > >> trying discover devices from my network. Hopefully nobody won't use USB >> > >> devices for any real AP stuff, but still enabling something which we >> > >> know doesn't work realiably is concerning. >> > > >> > > I agree. Maybe we should leave out the flag for AP mode in this patch >> > > until we have PS buffering and leave the rest of the code intact. >> > >> > At least for me that sounds good. >> >> We can support ps buffering in AP as well using a hrtimer. In this way we >> can reuse most of the existing code > > Yes, but there is issue to address, since kernel timer and device TBT > timer are independed, they possibly can get out of sync after some time, > for example few hours or days. So there is need to prevent/fix this > somehow. We could read the TSF timer value from the hardware and sync the hrtimer against that. - Felix
