Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Pete Heist <pete@heistp.net>
To: Cake List <cake@lists.bufferbloat.net>
Subject: [Cake] FreeNet update
Date: Sun, 10 Feb 2019 08:34:24 +0100	[thread overview]
Message-ID: <F08B37CA-5075-41CC-AA1D-65C22087E878@heistp.net> (raw)

We’ve got hfsc+fq_codel on one of our licensed spectrum full-duplex 100-Mbit backhaul links. I hope to switch to Cake, but I’m not yet sure the 3.16.7 kernel we’re using is stable enough to handle it.

I’d like to report how much better things are now even with fq_codel, but we keep finding (and fixing) problems elsewhere in the network that prevent us from actually filling the queue. The short list:

1) Switched TDD framing modes (Ubiquiti’s "flexible new" for now) as fixed framing was increasing RTT and killing download throughput (done)
2) Increased stability of CPE links (setting max tx rate, etc) to prevent loss / latency spikes that affect upstream ACKs and thus download throughput (done)
3) rx-vlan-offload must be broken in the r8169 driver in 3.16, was causing throughput problems for VLAN routing (fixed)
4) The current unsolved killer is a 0.03% downstream packet loss problem on the backhaul link itself, which per the Mathis equation does us no good

I can fill the queue on upload and show clear results with an rrul_up test, but not download yet, because of problem #4.

One thing that had to be handled right in the sqm setup script was VLANs, which I imagine most ISPs will have in the backhaul. The original qos script, using sfq, was adding qdiscs to both the VLAN devices (eth0.3300, etc) and the main devices on egress and ingress. This caused multiple problems:

- Routed packets would pass through three queues in each direction unnecessarily, and ingress shaping wasn’t needed in the backhaul anyway
- One-armed routers were effectively made half-duplex, because a qdisc was being added to eth0 without any filtering by VLAN, putting Internet facing and customer facing traffic on the same queue

Now I use tc filters to assign VLANs to queues and apply all qdiscs on eth0 under one hfsc/htb link sharing hierarchy.

So, one router almost done and 60 more to go, as we work to bloat up our queues so we can debloat them. :)

Sigh, I hope to get back to development soon. Enough for now, and thanks again to the list for the help…


                 reply	other threads:[~2019-02-10  7:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F08B37CA-5075-41CC-AA1D-65C22087E878@heistp.net \
    --to=pete@heistp.net \
    --cc=cake@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox