On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-fast <make-wifi-f...@lists.bufferbloat.net> 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 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.
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 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. > > 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 > <make-wifi-f...@lists.bufferbloat.net> wrote: >> >> On 20 Oct 2022, at 02:36, Sebastian Moeller <moell...@gmx.de> 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, >> > 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. >> >> I’m 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’t 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 written >> email: >> >> <https://developer.apple.com/videos/play/wwdc2015/719/?time=892> >> >> Stuart Cheshire >> >> _______________________________________________ >> Make-wifi-fast mailing list >> make-wifi-f...@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > 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-f...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
