LinuxKPI: add Exponentially Weighted Moving Average implementation

[bz]

Summary

Add DECLARE_EWMA() which expands to a per-name EWMA implementation
as used by multiple wireless drivers.

Sposnored by: The FreeBSD Foundation
MFC After: 2 weeks
Reviewed by:
Differential Revision:

Test Plan

Someone with maths/stats clue please verify that I got it right.
It's been a while.

[bz]

Adding Colin and David as reviewers as I think both know maths/stats very well.

[cperciva]

LGTM. I can certainly confirm that it computes *a* exponential weighted average; whether it's the one you want (in particular, with _p fractional bits being stored but not returned), I can't say.

[dwmalone]

Also looks good to me. Slightly pedantic suggestions:

1. If you wanted, you could probably change the "((x << (_p)) >> d) + (((ztm1 << d) - ztm1) >> d)" to "((x << (_p)) + ((ztm1 << d) - ztm1)) >> d", which (I think) would have similar risk of overflow but might keep an extra couple of bits of precision.

2. As Colin says, the interface truncates the _p fractional bits, rather than returning them. We could round instead, but if the Linux interface doesn't do that, we can live without it.

3. If you really wanted to be pedantic, you could check the x value that is passed in will not overflow when shifted.

[bz]

In D30415#683891, @dwmalone wrote:

Also looks good to me. Slightly pedantic suggestions:

I decided I'll get it in as-is and then any follow-ups will be a lot easier to deal with.

1. If you wanted, you could probably change the "((x << (_p)) >> d) + (((ztm1 << d) - ztm1) >> d)" to "((x << (_p)) + ((ztm1 << d) - ztm1)) >> d", which (I think) would have similar risk of overflow but might keep an extra couple of bits of precision.

2. As Colin says, the interface truncates the _p fractional bits, rather than returning them. We could round instead, but if the Linux interface doesn't do that, we can live without it.

I don't know what they do internally.

3. If you really wanted to be pedantic, you could check the x value that is passed in will not overflow when shifted.

I was thinking about checking for overflows; maybe we should address these three things?