Re: [Bloat] Buffer bloat at the sender

[d@taht.net (Dave Täht)]

Juliusz Chroboczek <jch@pps.jussieu.fr> writes:

>> Juliusz,  have you thought about the host case at all?
>
>> One of the places we're getting insane buffering is in the operating
>> systems themselves (e.g. the experiment I did with a 100Mbps
>> switch).
>
> Yes.  You have three to four layers of buffering:
>
>   (1) the device driver's buffer;
>   (2) the packet scheduler's buffer;
>   (3) TCP's buffer;
>   (4) the application's buffer.
>
> It will come as no surprise to the readers of this list that (1) and (2)
> are usually too large.  For example, (1) the ath9k driver has a buffer
> of 200 packets; and (2) the default scheduler queue is 1000 packets (!).

The ath9k driver I have has 512 buffers, organized into 10 queues of
various usages that I don't think are actually being used for much (need
a way to gain insight into the queue usage and qdisc interaction), with
TX_RETRIES set to 13. Fairly current openwrt head.

I've put a patch out there to reduce this to (I think) effectively a
queue depth of 3, retries of 4, throughout, and the results are thus far
amazing.

>
>> My intuition is that we have to do AQM in hosts, not just routers.
>
> Hmm... I would argue that the sending host is somewhat easier than the
> intermediate router.  In the sender, the driver/packet scheduler can
> apply backpressure to the transport layer, to cause it to slow down
> without the need for the lengthy feedback loop that dropping/delaying
> a packet in an intermediate router has to rely on [1].
>
> Unfortunately, at least under Linux, most drivers do not apply
> backpressure correctly.  Markus Kittenberger has recently determined [2]
> that among b43-legacy, ath5k, ath9k and madwifi, only the former two do
> the right thing.

I was wondering about madwifi in the context of the mesh potato. Thank you.

I have been looking over the mq qdisc, it's not clear how well it's
being used.

>
> --Juliusz
>
> [1] Now why did we give up on source quench again?
> [2] http://article.gmane.org/gmane.network.olsr.user/4264
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
Dave Taht
http://nex-6.taht.net