From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44485C77B61 for ; Mon, 24 Apr 2023 15:55:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232145AbjDXPzm (ORCPT ); Mon, 24 Apr 2023 11:55:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231851AbjDXPze (ORCPT ); Mon, 24 Apr 2023 11:55:34 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BCE7A246 for ; Mon, 24 Apr 2023 08:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=g/1mjGCfIMb4t/rbKxT9ddITJFCqtTNLvrrm2VBAcpU=; t=1682351718; x=1683561318; b=nPvoV1mY9ApoHa95gGUqRbtLa20zWaXI6nB4755ZAoijMx+ MCvwHa3/BvGyKjs9lcwaq2MOXzi+z4EhNw9fGbHAOE2Hb4s5npK3ivgNwALmNGZnXdKNzakY0xp0D gRrLL7ztYLIq+LrAytoa8HQFwT6RnYX9lZF2hmjB4ExsxS/0/qYi5eUtH7W2ZFUQX0dFEHWjCuIQy k0KrUb9n+sSAJe4H6b9Blx9geBX2CW/VASmgwsNVJcnY1ksAgechK1PuTgk1I61ENUsVOVCpXJwpb NJUX6YH0ezEvD2qrgS2rXRgvKpAA0fi7opb6YytFq7gyjNzoHzSvszJ5s7UtfV1w==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1pqyX4-007Iho-1u; Mon, 24 Apr 2023 17:55:14 +0200 Message-ID: Subject: Re: [RFC v2] average: rewrite for clearity From: Johannes Berg To: Benjamin Beichler , nbd@nbd.name, linux-wireless@vger.kernel.org Date: Mon, 24 Apr 2023 17:55:13 +0200 In-Reply-To: References: <20230421134604.211128-1-benjamin.beichler@uni-rostock.de> <3f505aba559d4ce068ef6d2fd7743045e0d93b9f.camel@sipsolutions.net> 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 X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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