On Thu, 2013-07-11 at 14:18 -0700, Dave Taht wrote: > I have incidentally long thought that you are also tweaking target and > interval for your environment?
Google data centers are spread all over the world, and speed of light was not increased by wonderful Google engineers, thats a real pity I can tell you. > > > Whole point of codel is that number of packets in the queue is > > irrelevant. Only sojourn time is. > > Which is a lovely thing in worlds with infinite amounts of memory. The limit is a tunable, not hard-coded in qdisc, like other qdiscs. I chose a packet count limit because pfifo was the target, and pfifo limit is given in packets, not in bytes. There is bfifo variant for a byte limited fifo, so feel free to add bcodel and fq_bcodel. Linux Qdiscs have some existing semantic. If every new qdisc had strange and new behavior, what would happen ? > > > Now if your host has memory concerns, that's a separate issue, and you > > can adjust the qdisc limit, or add a callback from mm to be able to > > shrink queue in case of memory pressure, if you deal with non elastic > > flows. > > So my take on this is that the default limit should be 1k on devices > with less than 256MB of ram overall, and 10k (or more) elsewhere. This > matches current txqueuelen behavior and has the least surprise. What is current 'txqueuelen behavior' ? Current 'txqueuelen behavior' is a limit of 16.000 packets on typical 10G hardware with 16 tx queues, not 1000 as you seem to believe. If txqueuelen was a percentage of available memory, we would be in a bad situation : With txqueuelen being 100 15 years ago, it would be 100.000 today, since ram was increased by 3 order of magnitude. 0.1 % would be too much for my laptop with 4GB of ram, and not enough for your 256MB host. I do not want to bloat codel/fq_codel with some strange concerns about skb truesize resizing. No other qdisc does this, with codel/fq_codel would be different ? This adds a huge performance penalty and latencies. A router should never even touch (read or write) a _single_ byte of the payload. Whole point having a queue is to absorb bursts : You don't want to spend cpu cycles when bursts are coming, or else there wont be bursts anymore, but losses episodes. _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
