Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bf641b6343baf9a810df41a5d68e0c073a059548.camel@sipsolutions.net>
Subject: Re: [RFC v2] average: rewrite for clearity
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>, nbd@nbd.name,
        linux-wireless@vger.kernel.org
Date:   Mon, 24 Apr 2023 17:55:13 +0200
In-Reply-To: <bea043c3-1cee-e2a6-ca4b-83e80404358c@uni-rostock.de>
References: <20230421134604.211128-1-benjamin.beichler@uni-rostock.de>
         <3f505aba559d4ce068ef6d2fd7743045e0d93b9f.camel@sipsolutions.net>
         <bea043c3-1cee-e2a6-ca4b-83e80404358c@uni-rostock.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2023-04-21 at 17:16 +0200, Benjamin Beichler wrote:
> >=20
> > So then we could say we'll just fix them, but what value actually makes
> > sense to init with? You don't necessarily know, right? Initially biasin=
g
> > towards the first value makes a lot more sense than initially biasing
> > towards zero, no? And then if you want to achieve that, now you have to
> > either use _add_or_init(), which is probably what people will do, but
> > that continues having the problem ...
>=20
> I left out the the individual fixes for users, but for the samples I=20
> looked into, either start values were given, or they were semantically=
=20
> extractable.
>=20
> e.g. virtios pkt_len=C2=A0 ewma is clamped anyways, so using the clamp bo=
rder=20
> or in between will be safe.
>=20
> Most others are signals-strengths, many of them also only for=20
> statistics, where a slow convergence is okay in my opinion.

Yeah I guess that's the thing, we can accept slower convergence in many
cases, and "safe" start values mean that mostly. But why accept it when
we don't have to?

> IMHO the net improvement is, that if you do not use the convenience=20
> add_or_init function, it simply resembles the ewma filter of a math or=
=20
> CS-textbook.=C2=A0

Not sure I see that as a good argument. The practical engineering side
tends to always be more complex than the theory, and that's not really
unexpected. We can comment why it's different :-)

> The original problem was, that the ewma had a surprising=20
> output in a special situation.

Right, but that's an implementation issue, because we thought 0 =3D=3D
uninit was clever, without realizing the corner case.

> But while writing the commit, I recognized, that the current ewma=20
> implementation is only for unsigned values, which means the problem=20
> really only happens for many consecutive 0 values. I try to think over,=
=20
> what this means for the proposal of Felix, but I'm not able to think=20
> about unsigned C-arithmetics today :-D

Not much really, I think? It eases thinking about it though :)

> If we use that fix, then we should have an additional compile time=20
> check, that the precision has at least 2 or 4 bits, to really avoid the=
=20
> problem, shouldn't we?

Yes. I think 1 bit is enough, but yes, it can't be 0 bits.

johannes