Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Pete Heist <pete@heistp.net>
To: Michel Blais <michel@targointernet.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Bandwidith rate by host instead of global while using [dual-]srchost and [dual-]dsthost
Date: Sat, 16 Jun 2018 21:20:22 +0200	[thread overview]
Message-ID: <7A2F7A22-9A94-49EE-835E-180CFBD9951D@heistp.net> (raw)
In-Reply-To: <CAAWM72UjVRFCrpApxJmJXjKb_AmLF_zd07OCDHxVJ-hWai2KRw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]


> On Jun 16, 2018, at 5:33 PM, Michel Blais <michel@targointernet.com> wrote:
> 
> I doubt any WISP (Ubnt main market) using Edgerouter for routing would activate codel since it would hurt badly forwarding performance. Anyway, just like for CMTS, WISP bottleneck is the wireless radio, not the router.


Hi Michel- badly hurt forwarding performance in what way?

The bottleneck is not always the wireless radio, particularly when the link is not over-provisioned. I’m working with a WISP that uses Ubiquiti gear and APUs in their backhaul that do soft rate limiting (on their stable links) with HTB and SFQ. In my lab tests using NSM5s and APUs, both Cake and fq_codel outperform SFQ in both inter-flow and (especially) intra-flow latency under load, so that’s why we’re working on switching to one or the other. HTB is needed though for customized fairness, as you noted in your original question.

Out-of-the-box performance of NSM5s with airMAX enabled leaves something left to be desired as far as latency under load goes, so one should either over-provision or do some kind of shaping. Compare:

airMAX enabled, default queueing:
https://www.drhleny.cz/nsm5-airmax/default_rrulbe/ <https://www.drhleny.cz/nsm5-airmax/default_rrulbe/>

airMAX disabled, cake queueing (enabling airMAX here hurts inter-flow latency):
https://www.drhleny.cz/nsm5/eg_csrt_rrulbe_eg_cake_40mbit/ <https://www.drhleny.cz/nsm5/eg_csrt_rrulbe_eg_cake_40mbit/>

By the way, if you note the isochronous spikes in the output, that appears to be due to a bug in the NSM5’s Ethernet or internal switch driver that has been fixed in LEDE/OpenWRT. If you or anyone else happens to have an NSM5, I’d appreciate your testing and adding to the thread, where I didn’t yet manage to convince Ubiquiti that it’s real and an issue:

https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spikes-about-once-per-second-even-just-to/td-p/2358704/page/2 <https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spikes-about-once-per-second-even-just-to/td-p/2358704/page/2>

I’m actively writing an article on this topic and will post when finished...


[-- Attachment #2: Type: text/html, Size: 3247 bytes --]

  reply	other threads:[~2018-06-16 19:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-11 15:43 Michel Blais
2018-06-11 17:44 ` Dave Taht
2018-06-11 19:44 ` Toke Høiland-Jørgensen
2018-06-11 19:54   ` Stephen Hemminger
2018-06-11 20:17     ` Dave Taht
2018-06-12  6:55       ` Pete Heist
2018-06-12 18:55         ` Dave Taht
2018-06-16 15:33           ` Michel Blais
2018-06-16 19:20             ` Pete Heist [this message]
2018-06-16 19:26               ` Pete Heist
2018-06-17 13:35             ` Toke Høiland-Jørgensen

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=7A2F7A22-9A94-49EE-835E-180CFBD9951D@heistp.net \
    --to=pete@heistp.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=michel@targointernet.com \
    /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