[Bloat] Tuning fq_codel: are there more best practices for slow connections? (<1mbit)

[Sebastian Moeller]

Hi Yutaka,


> On Nov 2, 2017, at 17:58, Y <intruder_tkyf at yahoo.fr> wrote:
> 
> Hi ,Moeller.
> 
> Fomula of target is 1643 bytes / 810kbps = 0.015846836.
> 
> It added ATM linklayer padding.
> 
> 16ms plus 4ms as my sence :P
> 
> My connection is 12mbps/1mbps ADSL PPPoA line.
> and I set 7Mbps/810kbps for bypass router buffer.

	That sounds quite extreme, on uplink with the proper link layer adjustments you should be able to go up to 100% of the sync rate as reported by the modem (unless your ISP has another traffic shaper at a higher level). And going from 12 to 7 is also quite extreme, given that the ATM link layer adjustments will cost you another 9% of bandwidth. Then again 12/1 might be the contracted maximal rate, what are the sync rates as reported by your modem?

> 
> I changed Target 27ms Interval 540ms as you say( down delay plus upload delay).

	I could be out to lunch, but this large interval seems counter-intuitive. The idea (and please anybody correct me if I am wrong) is that interval should be long enough for both end points to realize a drop/ecn marking, in essence that would be the RTT of a flow (plus a small add-on to allow some variation; in practice you will need to set one interval for all flows and empirically 100ms works well, unless most of your flows go to more remote places then setting interval to the real RTT would be better. But an interval of 540ms seems quite extreme (unless you often use connections to hosts with only satellite links). Have you tried something smaller?

> 
> It works well  , now .

	Could you post the output of "tc -d qdisc" and "tc -s qdisc please" so I have a better idea what your configuration currently is?

Best Regards
	Sebastian


> Thank you.
> 
> Yutaka.
> 
> On 2017年11月02日 17:25, Sebastian Moeller wrote:
>> Hi Y.
>> 
>> 
>>> On Nov 2, 2017, at 07:42, Y <intruder_tkyf at yahoo.fr> wrote:
>>> 
>>> hi.
>>> 
>>> My connection is 810kbps( <= 1Mbps).
>>> 
>>> This is my setting For Fq_codel,
>>> quantum=300
>>> 
>>> target=20ms
>>> interval=400ms
>>> 
>>> MTU=1478 (for PPPoA)
>>> I cannot compare well. But A Latency is around 14ms-40ms.
>> 	Under full saturation in theory you would expect the average latency to equal the sum of upstream target and downstream target (which in your case would be 20 + ???) in reality I often see something like 1.5 to 2 times the expected value (but I have never inquired any deeper, so that might be a measuring artifact)...
>> 
>> Best Regards
>> 
>> 
>>> Yutaka.
>>> 
>>> On 2017年11月02日 15:01, cloneman wrote:
>>>> I'm trying to gather advice for people stuck on older connections. It appears that having dedictated /micromanged tc classes greatly outperforms the "no knobs" fq_codel approach for connections with  slow upload speed.
>>>> 
>>>> When running a single file upload @350kbps , I've observed the competing ICMP traffic quickly begin to drop (fq_codel) or be delayed considerably ( under sfq). From reading the tuning best practices page is not optimized for this scenario. (<2.5mbps)
>>>> (https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/) fq_codel
>>>> 
>>>> Of particular concern is that a no-knobs SFQ works better for me than an untuned codel ( more delay but much less loss for small flows). People just flipping the fq_codel button on their router at these low speeds could be doing themselves a disservice.
>>>> 
>>>> I've toyed with increasing the target and this does solve the excessive drops. I haven't played with limit and quantum all that much.
>>>> 
>>>> My go-to solution for this would be different classes, a.k.a. traditional QoS. But ,  wouldn't it be possible to tune fq_codel punish the large flows 'properly' for this very low bandwidth scenario? Surely <1kb ICMP packets can squeeze through properly without being dropped if there is 350kbps available, if the competing flow is managed correctly.
>>>> 
>>>> I could create a class filter by packet length, thereby moving ICMP/VoIP to its own tc class, but  this goes against "no knobs" it seems like I'm re-inventing the wheel of fair queuing - shouldn't the smallest flows never be delayed/dropped automatically?
>>>> 
>>>> Lowering Quantum below 1500 is confusing, serving a fractional packet in a time interval?
>>>> 
>>>> Is there real value in tuning fq_codel for these connections or should people migrate to something else like nfq_codel?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Bloat mailing list
>>>> 
>>>> Bloat at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/bloat
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat