Re: [Bloat] Inaccurate rates with HTB/HFSC+fq_codel on router due to VLAN?

[Jonathan Morton <chromatix99@gmail.com>]

> On 18 Mar, 2017, at 17:34, xnor <xnoreq@gmail.com> wrote:
> 
> If I understood it correctly, and very simplified speaking, right now a queue is filled with link speed and drained by a configured bandwidth. As the pressure in a queue rises, packets will be dropped/marked to reduce pressure to some tolerable level.
> 
> Why not measure ingress rate (averaged over a window related to the configured rtt) and increase pressure if the ingress rate surpasses the configured bandwidth?

If the ingress rate is higher than the shaped rate, the queue will fill, and this will automatically trigger higher AQM activity.  There is no need to actually measure ingress rate to achieve this, and that’s not what autorate_ingress is meant for.

What you should be looking for is the number of dropped and marked packets.

Marked packets (which appear due to AQM activity on ECN-capable traffic) continue through to the receiver and inform it directly of congestion, which is then communicated to the sender, which in turn is supposed to reduce its congestion window to suit.

Dropped packets represent the *difference* between the ingress rate and the rate actually reaching the receiver, which is informed about congestion by detecting these packets’ *absence*.  It must then tell the sender to re-send those packets, resulting in *more* ingress traffic for a given goodput.

A useful experiment would be to reduce your shaped rate until you see an effect on  goodput (measured at the receiver) and ingress rate.  For example, configure for 5Mbps down and 1Mbps up, and see what you actually get.

On some hardware we have seen a perplexing doubling of the configured shaped rate.  This is not a bug in the shaper, but may be due to bad timer hardware which runs faster than realtime.  In this case you might see *no* marking and dropping when configured for the full rate intended.

 - Jonathan Morton