Hi All, I just wanted to say thanks for this discussion. I always learn from each and all of you.
Bob On Thu, Oct 20, 2022 at 12:40 PM Sebastian Moeller <moell...@gmx.de> wrote: > Hi Dave, > > > > On Oct 20, 2022, at 21:12, Dave Taht via Rpm <r...@lists.bufferbloat.net> > wrote: > > > > 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. > > [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... > > Regards > Sebastian > > > > > >> 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 > > _______________________________________________ > > Rpm mailing list > > r...@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/rpm > > -- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
