Jiri Benc wrote:
On Tue, 10 Jul 2007 21:59:13 -0700, Cahill, Ben M wrote:
Postponing the division keeps the running average using more significant
bits, so each new sample has a meaningful, surviving impact to the
running average. Sorry, "high-precision" is the best term that I can
think of to describe more bits being used in the running average. The
"binary point" is between bits 3 and 4; think of bits 3:0 as
"remainder".
Thanks, that makes sense. Please include something like this
explanation in the description of the patch when you resend it.
There is a subtle difference between:
1) last_rssi * 15 / 16
2) last_rssi - (last_rssi / 16)
The first one would get stuck at -801 if there were a series of -51s
coming in.
-801 * 15 / 16 would get quantized to -750 each time, so the output
would be stuck at -801 (-50 dBm).
The second one favors the high precision memory, and would progress from
-801 to -802, etc., as a series of -51s came in:
-801 - (-801/16) = -751
So it's basically just a different rounding - in the current code, it's
like float division with the result rounded down, while your change
makes it to round up (speaking about absolute value). Nothing about
precision here :-)
I saw 2 instances of sta->last_rssi being used in ieee80211_ioctl.c, and
STA_FILE(last_rssi, last_rssi, D) in debugfs_sta.c, which I didn't
understand (still don't) and was afraid to touch, so I thought the
safest thing with least impact would be to add the 3 additional
variables, and do the division in one place for each of the 3
rssi/signal/noise.
If we do the division when passing to user space, how should STA_FILE be
handled, if necessary?
Johannes was quicker than me (thanks) :-)
Thanks for your comments. I'll wait for your answer, and try again.
Thanks and sorry for the delayed answer,
I added the wireless statistics to d80211 (it was that long ago) and I used 16-point averaging based
on my experiences with an early version of the bcm43xx-softmac driver where the rssi value was quite
jittery. From a quick test on the current drivers, the assumptions seem not to be valid and it is
quite possible that averaging may not be needed, or that one can get by with a 2- or 4-point process.
My suggestion would be to circulate a trial patch with averaging removed and ask for testing to see
if it makes the results too jumpy. I can prepare that patch if you wish.
Larry
-
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
