One question about TCP small queues (which I don't think is a good solution
to the problem). For 802.11 to be able to perform well it needs to form
maximum size aggregates. This means that it needs to maintain a minimum
queue size of at least 64 packets, and sometimes more. Will TCP small
queues prevent this?
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On May 15, 2015 6:44:21 AM Jim Gettys <j...@freedesktop.org> wrote:
On Fri, May 15, 2015 at 9:09 AM, Bill Ver Steeg (versteb) <vers...@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:l...@netapp.com]
> Sent: Friday, May 15, 2015 8:44 AM
> To: Bill Ver Steeg (versteb)
> Cc: Aaron Wood; c...@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
----------
_______________________________________________
Bloat mailing list
bl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
