[Bloat] [Make-wifi-fast] [Rpm] The most wonderful video ever about bufferbloat

[Bob McMahon]

Intel has a good analogous video on this with their CPU video here
<https://youtu.be/o_WXTRS2qTY?t=316> 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.

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-fast at lists.bufferbloat.net> wrote:

> On 20 Oct 2022, at 02:36, Sebastian Moeller <moeller0 at 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-fast at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20221020/746697bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20221020/746697bc/attachment.bin>