From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 864A43B2A4; Thu, 20 Oct 2022 15:12:37 -0400 (EDT) Received: by mail-wm1-x332.google.com with SMTP id o20-20020a05600c4fd400b003b4a516c479so392153wmq.1; Thu, 20 Oct 2022 12:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xhmmcqKXwQyaqcb+O3KdnVsVG6Im1D0jMiuMhZUx3cc=; b=U/OrTyWHFZIDx2oxxja5XxQ+biZGCI4pwmDHxZLd4NzxGeVmQTxVslqNy/Q+9X5/NG 5DW2rB6Thm6M874q2fepv03+AqJqY2wqy+FQZ+7qyGbV7tkVEkaZnerUfXThTBy384zw R7J5wW0xsiCNeRgphPv+kn8NgkuJMieesCa+R9niG1v7z4+5MPl9xyGnq0WrnSzG60sj 6+0Lqw9nurRvJbOV9eKKgodGxVAN/NtzPEL5PRuAko5Dtjfhtco/QKJ2zx/13FiTmBDC asCtEduSHoRRJUPABdRISkbpA4ZxQHfGWsbjlHYYLwEAlHWNM3MiUvsG3T9/gINwsgL7 M9Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xhmmcqKXwQyaqcb+O3KdnVsVG6Im1D0jMiuMhZUx3cc=; b=kcCL2801e0QDn+YFEFXlNVPNQ16XddtR1PH4k5UNPD9UVev+ui1srsbjqNpjaMyO8o hm77NlC+NNf+Zm/sbHZXhqlKrPfx8uqN3yyVajp19yWDdbjbJ58kEOiQWLugt6X8ICvs YRgWBMG6cZm6XSkUJc6dlk8biR2nxmBBwlwCO3wHbF2MB5VHmBELsBBC/XsZcLCFPf+V 2rITtAxh+rvrvtI59KuzBFvG52f460nD+8CKJA9/vDOvjQtWsv6tZS8Di6ZWNLny9bk6 fCM6dhk8+QMCQREHoUbw7kVAGn1e92uO083NHLtV7fwhDiIuGXgQpamQ6WBmnTPT7KGd Gz8Q== X-Gm-Message-State: ACrzQf04j+ZSm40g8d+U4lWGMUD/kSNOd0zWYjy2yLTwd0z0jSDw31cT hGCsx+za+Rl7x0y5yiRK6MMypDd+2rBP6UfCino= X-Google-Smtp-Source: AMsMyM6mCI1gNl2wC9yeqldetEQNbjmm38zc38/gVQN9aPOh5WRffBsB5uG7pRY1+9dZkzDnASs5KB1OXZKPxT9VxQ0= X-Received: by 2002:a05:600c:54f2:b0:3c6:bd60:5390 with SMTP id jb18-20020a05600c54f200b003c6bd605390mr31022224wmb.206.1666293156478; Thu, 20 Oct 2022 12:12:36 -0700 (PDT) MIME-Version: 1.0 References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> In-Reply-To: From: Dave Taht Date: Thu, 20 Oct 2022 12:12:23 -0700 Message-ID: To: Bob McMahon Cc: Stuart Cheshire , Rpm , Make-Wifi-fast , Cake List , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:12:37 -0000 On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-fast wrote: > > 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 pip= elines make the forks worse in the amount of in-process bytes that need to = be thrown away. Interactivity, in my opinion, suggests shrinking the pipeli= ne because, with networks, there is no quick way to throw away stale data r= ather every forwarding device continues forward with invalid data. That's b= ad for the network too, spending resources on something that's no longer va= lid. We in the test & measurement community never measure this. 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. > There have been a few requests that iperf 2 measure the "bytes thrown awa= y" per a fork (user moves a video pointer, etc.) I haven't come up with a g= ood test yet. I'm still trying to get basic awareness about existing latenc= y, OWD and responsiveness metrics. I do think measuring the amount of resou= rces spent on stale data is sorta like food waste, few really pay attention= to it. > > Bob > > FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested. > > --tcp-write-prefetch n[kmKM] > Set TCP_NOTSENT_LOWAT on the socket and use event based writes per select= () on the socket. > > > 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: >> >> > Hi Stuart, >> > >> > [SM] That seems to be somewhat optimistic. We have been there before, = short of mandating actually-working oracle schedulers on all end-points, in= termediate hops will see queues some more and some less transient. So we ca= n 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 lettin= g information get stale in their own buffers as compared to an on-path queu= e. Think an on-line reaction-time gated game, the need is to distribute cur= rent world state to all participating clients ASAP. >> >> I=E2=80=99m afraid you are wrong about this. If an on-line game wants lo= w delay, the only answer is for it to avoid generating position updates fas= ter 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 th= em to the destination faster; it gets them there slower. The same applies t= o 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 s= itting 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. >> >> Please watch this video, which explains it better than I can in a writte= n email: >> >> >> >> Stuart Cheshire >> >> _______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > This electronic communication and the information and any files transmitt= ed 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 contai= n information that is confidential, legally privileged, protected by privac= y laws, or otherwise restricted from disclosure to anyone else. If you are = not the intended recipient or the person responsible for delivering the e-m= ail to the intended recipient, you are hereby notified that any use, copyin= g, distributing, dissemination, forwarding, printing, or copying of this e-= mail is strictly prohibited. If you received this e-mail in error, please r= eturn the e-mail to the sender, delete it from your computer, and destroy a= ny printed copy of it._______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC