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 749DD3B2A4; Thu, 20 Oct 2022 15:40:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1666294824; bh=L3uu7kag8yrpU4eFT+i5BIaM8fzo7hT9qNRVa8zStfE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=YCzmioV3+o5Xyw1/uwuSwQ95ksJ4yEeKlPcSwjciUGENxVLv88alOHdqYdMk8Q9mA ZANFkoeRR8k2Tse+Ion9pdxn4EQoquHHCc2FPggodZbwh30vcLexd+bvO5EYl4Zmc6 uvF7Jj08WAxuLjkmZG36WMoaI55EX/yeo7BUQev0= 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 1MOzT4-1oSzgq189M-00PPFY; Thu, 20 Oct 2022 21:40:24 +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:40:22 +0200 Cc: Bob McMahon , Rpm , Cake List , bloat , Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <32CFC6B2-87E5-4463-B197-D297C3628C7D@gmx.de> References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:+zVxN6/DpHUl3uIk2dtlBxrKeW7rmK4YAOql6g/TD356Gxml2+j hh0IyNWIiO72shiRvyXFpwVZ0/zsexIHEp2p8V1buLpY0LHx7NP8XNWeuMvPZDyozS+RcwR 59ZDexPZi/4+/O1+xiJjYoaK7RXc6cgtydn+rrny0+7SOI3U6cQHptlzJLdFIJWcqykpbW9 pgakLCvdXJnDKeSJ8bVRw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+Ey3ltkIb1k=:DQnTbZ2NJEBfe/PSoK+hWR IkSmQMuNe1NGHwy+16JF9uEH300hhAq3NcrkmTL+nJGwe0uZc2BtgsSgoItqig13Et9cWfsKN Umwe4HWgS2ukp1DGWdjLMgsg6lWMR8XA8eHV7/QmIU8hp9aboA8YH+lYLqT7zj1GScau+MOAV RX8OAEnOEgFdgD/eo7/j/1qzlXi8KtC+RcvZk7Jll7ZvVk7wMlXee7v1JpZDA8glDAeIE5RUf xYJ1o+tCKhxrJr48VOLHb/ym/XZhuA1P+kc+M9lmKj0bngAzhb302f6AbrwOAUAQ9VDhoQey9 qtob9UCa1X0NcSMIMt08hetyHX8IveeqRB8BQTDdv8FPFLIqa86kIGvsvDBoe7A/dQDZnMq+p xsunviTNrW9Hb3kYurN1VaxZU5OfUba1ITT1cf0X95l7tZ9+kDBQP8sC4ZUnA4thXf+j52+fC 0za1MjtJfx4taxJNiKzjqlkiEUQLePlUJS1ZG6b+BbmUiNwTabnF7eubgPYfT+eSexa/1Ptjf wyIWN+uYbC88HAuAofbY6L1avMwAjRfZGTw6P8U79+OUSIpRh6CdJ6cYV7RuUFoSoI8cYYqla UNNjPucGQGEoGRKa97gMWPOlTaeJVnw4jPrEHWzT8jWBrYCo256UXxe/fBUFEJ8iG4b0gMjWj /eNFbQA2mbkmjge1htmU6xP/v9iqXSp/Q2n1EoZoFg1v/gaSlMNKugRE6LWsNv/XYUX1eqagK pXBnikpKMYZ6kszSph12z7TSdBjHIBQtuT8Q96nRE3PLOnn5ltVZJPB78alGq8tliJH/DzoB9 uVPE7B7KsBFtCvuafVIxkgLcUYM+3HoVC6Njnu205daAJqcKTvdsmjnuWGwhf2kgSbZoLSgRO SirTZJQ7rqFaRe64DnTvK4sT3MXjqTll8pPOOcMXx8rpFANk6NFHAtuvRs9e/78XO+eByw6dl C1CyIQwY+nt9S3cKONtr9S16jV4BAX4w7DYvM78xCyq3KT6tYAIKlCCjYpitKx5MVfs78Fz3g ifn9SQBjIsd8B6p/dtWjJeNLDIGFG15Hx4oKP6NnZ4c6kMwnqr5BUmAkD31+vyh1fzkMK2Ylz TjH8eWzZ+nqrn9f+xrHDNW1cfm+CQN1KX+sSKyElbfTM0wcxLBixCeKs/xnfDXDeEMpgB85ZA 84OkaUxegNMwXu25Rl31mlub4DkSwXR2bbinwS59fYUl3hTpvdg86gH24+rxLWdubZJiVkFbx qZrf05IoBj8NOAHPHq89E8ulNUeufrhp5G/3CSXvCAhGnauR19LD9LdqBkhAKapmLCTOvwgIP ySzQ9pJXL7y3KwWCv5CCFY2bOsGMC8TwyOzq+uXS5Za8wVPuja/tqByPB0wWJ59n4FOccxr28 Qxe8kNgfLuHnEgR/ZNFoK6Gbt93lUnHoWIIekp2qtaFk5tjeZSvohVyXPp4ir6ZWYT9vIZYP2 KFyw6D4wsiegEoKpXG4dAp5YAfSxh3OMg8WptCwryy9GRN0nHL7agn4G48JYGzC8Eb2MHK/pq T7N4CGBg6MkW/oBHcB+5DA7GajIDcA81oKca21q4ezCpb Subject: Re: [Bloat] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2022 19:40:26 -0000 Hi Dave, > On Oct 20, 2022, at 21:12, Dave Taht via Rpm = wrote: >=20 > On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-fast > 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 > One of my all time favorite demos was of stuart's remote desktop > scenario, where he moved the mouse and the window moved with it. [SM] Fair enough. However in 2015 I had been using NX's remote = X11 desktop solution which even from Central Europe to California = allowed me to remote control graphical applications way better than the = first demo with the multi-second delay between mouse movement and = resulting screen updates. (This was over a 6/1 Mbps ADSL link, = admittedly using HTB-fq_codel, but since it did not saturate the link I = assign the usability to NX's better design). I will make an impolite = suggestion here, that the demonstrated screen sharing program simply had = not yet been optimized/designed for longer slower paths...=20 Regards Sebastian >=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 >> --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: >>>=20 >>> 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 >>=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._______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast >=20 >=20 >=20 > --=20 > This song goes out to all the folk that thought Stadia would work: > = https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665= 607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm