Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Fri, May 15, 2015 at 9:09 AM, Bill Ver Steeg (versteb) <versteb@cisco.com
> wrote:

> Lars-
>
> You make some good points. It boils down to the fact that there are
> several things that you can measure, and they mean different things.
>
> Bvs
>
>
> -----Original Message-----
> From: Eggert, Lars [mailto:lars@netapp.com]
> Sent: Friday, May 15, 2015 8:44 AM
> To: Bill Ver Steeg (versteb)
> Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl;
> cerowrt-devel@lists.bufferbloat.net; bloat
> Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs
> cablemodems
>
>
> I disagree. You can use them to establish a lower bound on the delay an
> application over TCP will see, but not get an accurate estimate of that
> (because socket buffers are not included in the measurement.) And you rely
> on the network to not prioritize ICMP/UDP but otherwise leave it in the
> same queues.
>

​On recent versions of  Linux and Mac, you can get most of the socket
buffers to "go away".  I forget the socket option offhand.​

​And TCP small queues in Linux means that Linux no longer gratuitously
generates packets just to dump them into the queue discipline system where
they will rot.

How accurate this now can be is still an interesting question: but has
clearly improved the situation a lot over 3-4 years ago.​


> > If you can instrument TCP in the kernel to make instantaneous RTT
> available to the application, that might work. I am not sure how you would
> roll that out in a timely manner, though.
>
> ​Well, the sooner one starts, the sooner it gets deployed.​

Jim

[-- Attachment #2: Type: text/html, Size: 2936 bytes --]