Re: [PATCH v4 3/5] cfg80211: Accept multiple RSSI thresholds for CQM

[Johannes Berg <johannes@sipsolutions.net>]

> > I think it would make sense to unconditionally apply the hysteresis
> > to low/high, i.e. always set
> >  low = low - hyst
> >  high = high + hyst
> > 
> > so that you get "sticky" ranges once you're in them?
> 
> Yes, maybe that's better, I guess I want to avoid just adding a lag /
> delay in reporting changes that are not due to measurement error or
> temporary.  Could also do something in between, e.g. use "low - hyst"
> if signal is close to low, otherwise just "low".

That's sort of what you had, but except for the precise definition of
"close", no?

Actually, no, because you used "last - hyst" rather than "low - hyst"
it's different. I think we can live with checking if it's close, say
setting to "low - hyst" when it's within low + hyst - that avoids the
problem I outlined above and gets a bit more responsiveness, I guess.

> The question is how the current hysteresis parameter is defined, what
> is expected of the firmware and how do driver authors decide whether
> their firmware/hardware implements the same mechanism as expected by
> the kernel.  Would the same thing happen with firmware
> implementations if the hysteresis value is 3 and the rssi fluctuates
> by +/- 2?  Or would it have to be +/- 3 or +/- 4 before this starts
> to happen.  (If this isn't well specified then it makes more sense to
> try to do it in one place for consistency.)

I'm not sure it's well-defined.

johannes