From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 2.mo5.mail-out.ovh.net (2.mo5.mail-out.ovh.net [178.33.109.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C4C4421F212 for ; Mon, 23 Nov 2015 01:50:36 -0800 (PST) Received: from mail624.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo5.mail-out.ovh.net (Postfix) with SMTP id D1BB1FF9D21 for ; Mon, 23 Nov 2015 10:50:34 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 23 Nov 2015 11:50:32 +0200 Received: from mail-wm0-f54.google.com (mail@frentzel.eu@74.125.82.54) by ns0.ovh.net with SMTP; 23 Nov 2015 11:50:30 +0200 Received: by wmec201 with SMTP id c201so151702979wme.0 for ; Mon, 23 Nov 2015 01:50:26 -0800 (PST) X-Received: by 10.28.54.165 with SMTP id y37mr18895927wmh.55.1448272226239; Mon, 23 Nov 2015 01:50:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vincent Frentzel Date: Mon, 23 Nov 2015 09:50:16 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a114306d2954dcd0525322726 X-Ovh-Tracer-Id: 16241669108212156915 X-Ovh-Remote: 74.125.82.54 (mail-wm0-f54.google.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrjedtucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrjedtucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Cc: "cake@lists.bufferbloat.net" Subject: Re: [Cake] Cake performance optimization X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 09:51:00 -0000 --001a114306d2954dcd0525322726 Content-Type: text/plain; charset=UTF-8 Sounds encouraging. Just a note/thought... I am actually not running ingress through the IFB. I set the download speed to 0 and perform egress shaping on the lan bridge iface (br-lan). Maybe not the lightest setup, but this gives a really high flexiblity to classify the ingress traffic (ie. I dont have to use best effort nor trust the incoming DSCPs which are anyway tweaked by my provider). On x86_64 I agree with your observation, no speed problem there. But running a 1.83 Ghz box for routing 4 devices is a tad overkill :) I use the connmark stuff to reclass tcp streaming traffic from CS0 to AF4x and udp traffic to EF (Netflix/Youtube and Voip respectively). I also apply priority to DNS (AF4x), NTP (EF), SSH (AF4x) and deprioritize some traffic to CS1. I do this in my firewall3 config and firewall.user (some of my rules are MAC based -> chromecast, nas box, etc..). I set the mark and connmark save it on egress, on ingress (egress of the other iface) I simply restore the mark. In an ideal world... all apps would apply meaningful DSCPs to their packets and this classification would not be needed. In general, I tend to trust the DSCPs on egress and dont override them, on ingress I squash everything. I used to run htb + fq_codel and performance was awful, cake performs *much* better. --001a114306d2954dcd0525322726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds e= ncouraging. Just a note/thought... I am actually not running ingress throug= h the IFB. I set the download speed to 0 and perform egress shaping on the = lan bridge iface (br-lan). Maybe not the lightest setup, but this gives a r= eally high flexiblity to classify the ingress traffic (ie. I dont have to u= se best effort nor trust the incoming DSCPs which are anyway tweaked by my = provider).

=
On x86_64 I agree with your observation, no speed problem there.= But running a 1.83 Ghz box for routing 4 devices is a tad overkill :)

I use the connmark stuff to reclass= tcp streaming traffic from CS0 to AF4x and udp traffic to EF (Netflix/Yout= ube and Voip respectively). I also apply priority to DNS (AF4x), NTP (EF), = SSH (AF4x) and deprioritize some traffic to CS1. I do this in my firewall3 = config and firewall.user (some of my rules are MAC based -> chromecast, = nas box, etc..). I set the mark and connmark save it on egress, on ingress = (egress of the other iface) I simply restore the mark.=C2=A0In an ideal world... all apps would apply meaningful DSCPs= to their packets and this classification would not be needed. In general, = I tend to trust the DSCPs on egress and dont override them, on ingress I sq= uash everything.=C2=A0

I used = to run htb=C2=A0+ fq_codel and performance was awful, cake performs *much* = better.

--001a114306d2954dcd0525322726--