From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A88123B2A4; Thu, 20 Oct 2022 15:33:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1666294387; bh=0EKZD85CU9D6OZ3G0D7t2LRHiC29FDm2TqCFnV0Wqa4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZlGE8KFvR3QKaycn5N1zthUtlgo1iiLR/OX3e/sfkMu/YEh0PQWIuVNdi9J71eJzm yACVLrxzeJ834oYBb/Qh0RVugW8fuCPpkYbIxreVQraLgy1EroGMMyf59D7JlHf4BN umsemi1nqPLY5G8AzIfirecZCdzc6ppWdlSCg1No= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([79.195.171.215]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MnJlW-1pUWwh3OYW-00jG9F; Thu, 20 Oct 2022 21:33:07 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 20 Oct 2022 21:33:05 +0200 Cc: Stuart Cheshire , Rpm , Make-Wifi-fast , Cake List , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> To: Bob McMahon X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:3TPLU3+9idYKuUzV8kWvI4z49/1GINvNSc1DFDszKxklTC4OLsH pdgs9aYeg2ifm8C67fHnaEI+Qx6NzLMCvn8e8fYpIYQtkaHm2XWjNBX5fN7OFwpIBMLt9r4 YUAXeNIx2zgh4x73oXKe7kqoWUs6wsnhfmmlSSzp6kc4AcRAw8hhaa9pEVj60dTyQ6UTo/v VwByRciRH8efjWK/iQKpA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:IczP++W7cFU=:IxrXMkgoZrdL5T85vJvtAf 5t4GhRxxijX6mGdpvBcWYvE5T/ffkLprx5s9xVGO0TJFePVelq5oCnixU83UY3kRk06SsmvI1 5EHQSDe7HaP4gWeeuN2DoA+YMLtzGEfH0OpSDC9oquwro+HTd43zciHnrw0PEwaYn2WcPEyQn kNnsoeBJFvdVy1/j5pGfdmSM9Eje092wu+aj7iLkVovcp2WO7xvEuKAXE4GR6cepvFQXANjL2 49JckAIqJ6uvHt/77/YbrugLtNLNpw6zYaINABQnHwoWKK6OIQ8D72q4DURQBROw9/kwzwfdv yQqKNoY8Ksd+VLNnYrPH38jXIyrCwlYu9Fbw09SPOSdt6I/AP3Ni2VCOFMLSBrc+8io2E0tKf 7T8WuFeCsQMsEsatNUzM5xZkJJK2UiRcIHpKDnykKCF3UlQtJA8WReGyuxquWjHyqJhtv+cV+ jV7dyarTQsnNuuWaOIjsiN877GrS8oCFyoXLLExbaHPtW0sxUVKWjaoTfZWnnY//URSbfIB/V oeRxDMmKD1rgnApt60iV/B2XPI2Drgm4GfR35/6EN4WS4J55kbB3jcWeRwqLoXsqXtIN5pQLl Ub/4e6IT8wKEqvQRri4RsIYke/mQ9LI7FPaGqUvtxbSOCvCPIcCSaCUQcT2ogFuW3fek1RvjB xIViFXkAb91WKG+9rNyFoj0LnsogkCk65kaWOiBoOZKdZu7pbK8kun4IZAtSF18jSW4D1B9MR Uy72jB3xPA5rUo1bkIuQ1enJYo4I/Ofaa11God4JZlCp98x6xReI+GhmSU6NsXI3etWhGsBNl eWfp4kmjhPbZBfJNY/fvLIbXlH6GR2ZK8pONALD+TqvRy3vDjEYGo/y8F528cUq2biNyRcF8L udhUpY5kUpGHeRa616vrGP1iaIa1n/UhaisUrOv9lZSGKapuhoM4Qr4Gb30OFmK/5kinG++Q2 NwnzrXT4+FtJuvjIS9ufaKEhgw21Sc8FcN8enMR3R4mSaQ6f9+NVBWXGuuqDPWXzJve0/b8Ev MS/J3zBCpYYqni30L2pE6I/cTaKzdNJGNeAqGD7kNVGJnCiByQaQ82gxNWKJ5KB/vM+ctrOS7 CYiixbzbAg2HMKSoQ/JiP9Q8UwORnD5mZz2SL0FXeCxYW1l3ppc/+rM6aoj2Go7P3WbnVJsbP De3Z5I3jzHqf4uvGiJfIJsqDS7aP10NZLLfq4fUx73LQSWUxv2cR48rDcQl/+yfIlBCgMCOK9 BVENjpwdm6PnRJ++SVxlF2CLS/cEdoxW6+Lq9QHnLvMRX1hFsRyu3FaRO+TF6rtDlcXJBZadc pbYgBEKHTONtvI9326o1dyoIPbIvL/pEF4sJYB5OfSQ0UFJE/zhuLS4SL/8eVuEJtYr/aDdDs EFaj+tpoCMHUYVK6JF7Z7RhmciOQCIuouhopRrTFcfVlQyoNvJqc758NUuTfV1Z/68G891pUO Wb9Da8ahlB90AEuMsNVkXkIaJx6XXW6QIDlpAxdp//nDDZ67rKy1W1lM2NveDVskQc2L6H89o SmDlbxDHvQWFrnvvZ8yahyGLH7hyCJkfVhPXi/gDREZO2 Subject: Re: [Cake] [Make-wifi-fast] [Rpm] The most wonderful video ever about bufferbloat X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2022 19:33:19 -0000 Hi Bob, I think I agree, I also agree with the goal of keeping queues small to = non-existent, all I am saying is that this is fine as a goal, but = unrealistic as a reachable end-point. Queues in the network serve a = purpose (actually multiple) and are not pure bloat. The trick is to keep = the good properties while minimizing the bad. The way I put it it is: over-sized and under0managed buffers/queues are bad, the solution is not = to get rid of queues but to size them better and more importantly manage = them better. Which will result in overall less queue delay, but = critically not zero queue delay. Regards Sebastian > On Oct 20, 2022, at 21:04, Bob McMahon = wrote: >=20 > Intel has a good analogous video on this with their CPU video here = going over branches and failed predictions. And to Stuart's point, the = longer pipelines make the forks worse in the amount of in-process bytes = that need to be thrown away. Interactivity, in my opinion, suggests = shrinking the pipeline because, with networks, there is no quick way to = throw away stale data rather every forwarding device continues forward = with invalid data. That's bad for the network too, spending resources on = something that's no longer valid. We in the test & measurement community = never measure this. >=20 > There have been a few requests that iperf 2 measure the "bytes thrown = away" per a fork (user moves a video pointer, etc.) I haven't come up = with a good test yet. I'm still trying to get basic awareness about = existing latency, OWD and responsiveness metrics. I do think measuring = the amount of resources spent on stale data is sorta like food waste, = few really pay attention to it. >=20 > Bob >=20 > FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested.=20 >=20 > --tcp-write-prefetch n[kmKM] > Set TCP_NOTSENT_LOWAT on the socket and use event based writes per = select() on the socket. >=20 >=20 > On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire via Make-wifi-fast = wrote: > On 20 Oct 2022, at 02:36, Sebastian Moeller wrote: >=20 > > Hi Stuart, > >=20 > > [SM] That seems to be somewhat optimistic. We have been there = before, short of mandating actually-working oracle schedulers on all = end-points, intermediate hops will see queues some more and some less = transient. So we can strive to minimize queue build-up sure, but can not = avoid queues and long queues completely so we need methods to deal with = them gracefully. > > Also not many applications are actually helped all that much by = letting information get stale in their own buffers as compared to an = on-path queue. Think an on-line reaction-time gated game, the need is to = distribute current world state to all participating clients ASAP. >=20 > I=E2=80=99m afraid you are wrong about this. If an on-line game wants = low delay, the only answer is for it to avoid generating position = updates faster than the network carry them. One packet giving the = current game player position is better than a backlog of ten previous = stale ones waiting to go out. Sending packets faster than the network = can carry them does not get them to the destination faster; it gets them = there slower. The same applies to frames in a screen sharing = application. Sending the current state of the screen *now* is better = than having a backlog of ten previous stale frames sitting in buffers = somewhere on their way to the destination. Stale data is not inevitable. = Applications don=E2=80=99t need to have stale data if they avoid = generating stale data in the first place. >=20 > Please watch this video, which explains it better than I can in a = written email: >=20 > >=20 > Stuart Cheshire >=20 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast >=20 > This electronic communication and the information and any files = transmitted with it, or attached to it, are confidential and are = intended solely for the use of the individual or entity to whom it is = addressed and may contain information that is confidential, legally = privileged, protected by privacy laws, or otherwise restricted from = disclosure to anyone else. If you are not the intended recipient or the = person responsible for delivering the e-mail to the intended recipient, = you are hereby notified that any use, copying, distributing, = dissemination, forwarding, printing, or copying of this e-mail is = strictly prohibited. If you received this e-mail in error, please return = the e-mail to the sender, delete it from your computer, and destroy any = printed copy of it.