Even single user, bufferbloat matters. Windows update will kill your
Skype call. Without large size aggregates the necessary physical layer
per packet overheads caused by the RF medium kill your efficiency and
performance. Fairness between users is another issue as well.
Simon
On 5/17/2015 8:30 PM, dpr...@reed.com wrote:
What's your definition of 802.11 performing well? Just curious.
Maximizing throughput at all costs or maintaing minimal latency for
multiple users sharing an access point?
Of course, if all you are doing is trying to do point-to-point outdoor
links using 802.11 gear, the issue is different - similar to
"dallying" to piggyback acks in TCP, which is great when you have two
dimensional flows, but lousy if each packet has a latency requirement
that is small.
To me this is hardly so obvious. Maximizing packet sizes is actually
counterproductive for many end-to-end requirements. But of course for
"hot rod benchmarkers" applications don't matter at all - just the
link performance numbers.
One important use of networking is multiplexing multiple users.
Otherwise, bufferbloat would never matter.
Which is why I think actual numbers rather than "hand waving claims"
matter.
On Friday, May 15, 2015 10:36am, "Simon Barber" <si...@superduper.net>
said:
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 <mailto: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
<mailto:l...@netapp.com>]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Steeg (versteb)
Cc: Aaron Wood; c...@lists.bufferbloat.net
<mailto:c...@lists.bufferbloat.net>; Klatsky, Carl;
cerowrt-devel@lists.bufferbloat.net
<mailto: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
