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: <bea043c3-1cee-e2a6-ca4b-83e80404358c@uni-rostock.de>
Date:   Fri, 21 Apr 2023 17:16:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [RFC v2] average: rewrite for clearity
Content-Language: de-DE
To:     Johannes Berg <johannes@sipsolutions.net>, <nbd@nbd.name>,
        <linux-wireless@vger.kernel.org>
References: <20230421134604.211128-1-benjamin.beichler@uni-rostock.de>
 <3f505aba559d4ce068ef6d2fd7743045e0d93b9f.camel@sipsolutions.net>
From:   Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>
Organization: =?UTF-8?Q?Universit=c3=a4t_Rostock?=
In-Reply-To: <3f505aba559d4ce068ef6d2fd7743045e0d93b9f.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Precedence: bulk

Am 21.04.2023 um 16:37 schrieb Johannes Berg:
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
>   Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und Anh=C3=A4nge,=
 nachdem Sie die Vertrauensw=C3=BCrdigkeit der Absenderadresse gepr=C3=BCft ha=
ben.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F
>
> On Fri, 2023-04-21 at 13:46 +0000, Benjamin Beichler wrote:
>> Move the former *=5Fadd function with its implicit initialization into a
>> separate function, when the user explicitly wants to init with the first
>> added value, although this creates issues, when 0 is a expected value for
>> the internal value.
>>
>> Add a separate init function with value parameter to allow init with
>> distinct value, which was formerly done by the implicit init of old
>> *=5Fadd function.
>>
> Sure, this is what you said :-)
>
> I still don't really think it's feasible. First, this breaks all the
> users, because if you have e.g. virtio's DECLARE=5FEWMA(pkt=5Flen, 0, 64)
> then it will take a long time to get away from 0.
>
> So then we could say we'll just fix them, but what value actually makes
> sense to init with=3F You don't necessarily know, right=3F Initially biasing
> towards the first value makes a lot more sense than initially biasing
> towards zero, no=3F And then if you want to achieve that, now you have to
> either use =5Fadd=5For=5Finit(), which is probably what people will do, but
> that continues having the problem ...

I left out the the individual fixes for users, but for the samples I 
looked into, either start values were given, or they were semantically 
extractable.

e.g. virtios pkt=5Flen=C2=A0 ewma is clamped anyways, so using the clamp borde=
r 
or in between will be safe.

Most others are signals-strengths, many of them also only for 
statistics, where a slow convergence is okay in my opinion.

> I don't really see how this is a net improvement - we'd still have to
> fix the individual users with it, e.g. maybe the mesh case that started
> this investigation could bias towards success (init with 100) and then
> use =5Fadd() rather than =5Fadd=5For=5Finit(), but then again we're back to
> having to make individual choices with the users. I don't really see how
> that's better than fixing it for real with the existing behaviour of
> biasing towards the first value=3F

IMHO the net improvement is, that if you do not use the convenience 
add=5For=5Finit function, it simply resembles the ewma filter of a math or 
CS-textbook. The original problem was, that the ewma had a surprising 
output in a special situation.

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

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

Benjamin