Current wisdom for setting fq_codel target?

Hi,

Trawling through all the documentation I can find online seems to suggest that fq_codel target parameter should be set to 5ms or the amount of time it takes to transmit 1x mtu sized packet. With interval being set 5-10x target.

I have a ~70 down ~20 up VDSL 2 connection. Overheads are definitely set correctly and I am having trouble with steam downloads causing excessive packet loss. I have hfsc based rate limiting to ensure I am in control of the buffer.

Steam downloads are automatically categorised into my bulk queue after some seconds. I find that large amounts of packets are dropped when target is set to 5ms; overall jitter in my priority queue is around 15ms when fully loaded. Analysis of pcap files suggests with target set to 5ms there is approx 3% retransmission rate for the steam download. With target set to 100ms drop rate is far lower and jitter in priority queue (which has target of 5ms still) is on the order of 6ms.

So what is the current best practice for setting target/interval values?

Interval should be in the ball park of your typical RTT (rather err on interval being a bit too large), as that effectively fq_codel will allow each flow to respond to a drop/marking signal. If interval is smaller than the real RTT such a flow will see more drops/markings than necessary and as a result achieve less throughput; if a flow's RTT is smaller than interval, but the flow is responsive nothing really bad will happen (unresponsive flows however will be more mischievous, but the fq part of fq_codel will mainly restrict the fall-out to the mischievous flow itself). In reality the default interval of 100ms works reasonably well for real RTTs from say 20 to 200ms..
Target should be set to 5-10% of interval, but at least allow a full MTU packet as you note.

That said, cake in its diffserv modes will give the bulk tin a somewhat higher target and interval (it still keeps close to the target = 0.05 * interval rule) on the rationale that for bulk flows one will happily accept a bit more bufferbloat for a higher potential throughput, after all that is one of the definitions of "bulk" that interactivity does not really matter.