From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AB6F021F210 for ; Sun, 20 Dec 2015 04:06:19 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id or18so1061134obb.0 for ; Sun, 20 Dec 2015 04:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=wtMiKE6xuNF1gtqLiSIm2SiO7p1LCVG3v6OGCLkPew0=; b=xb4vYJqiMicJIOrlreFa1JKUrq6xTsjuWsHtyOKD59FbcKOC1JVD2f1VGa7F7zcpbO mjKN7qJFa2ExGNnPSsLACXPrc/Heya/wgPTJwuVM+SfrwPqpMLPe+o9a325AfPbr9Ggc o/YIOGi8FrSMvp0wLqub6YEim9GBl+EPydg6lQ4v4BsM3mLSuaCuXVJqw0/p1MAGzKkS QnOkcBtvHHDsuV+3sHYo1cjgB99r4TzOGNe+HN3QluQ6agt3+rN85xgrt5MXt/l/4tQq 2J19Z2a6jUvFlhRISPb4VC3bvH8lrzAVSmhLlSkstOSZisiG5/KP1Kyhw/K+MHVExp9j 9aCg== MIME-Version: 1.0 X-Received: by 10.182.251.130 with SMTP id zk2mr5093893obc.57.1450613178386; Sun, 20 Dec 2015 04:06:18 -0800 (PST) Received: by 10.202.187.3 with HTTP; Sun, 20 Dec 2015 04:06:18 -0800 (PST) Date: Sun, 20 Dec 2015 13:06:18 +0100 Message-ID: From: Dave Taht To: Frits Riep Content-Type: text/plain; charset=UTF-8 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Cake on OpenWRT community builds and my observations 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: Sun, 20 Dec 2015 12:06:41 -0000 On Tue, Dec 8, 2015 at 3:02 AM, Frits Riep wrote: > First of all, I would like to thank all of the contributors for their hard > work and good progress in the challenge of combating bufferbloat! we appreciate the appreciation. > Most IT professionals and users still have no idea of issue or the potential > fixes, and so awareness in the larger community is still a major issue. Sigh. fix it for two friends, ask them to fix it for two friends, and we'll get there. I keep hoping someday soon I'll see http://www.dslreports.com/speedtest/results/bufferbloat?up=1 have more stuff move up and closer to the green line.... > I had in the past used Cerowrt builds and other openwrt builds with fq_codel > and also have been very happy with the results. > I'd like to provide some feedback on my experiences with Cake so far. I > just updated my TP-Link Archer C7 to an OpenWRT image which was pre built > with sqm-scripts and I was very pleasantly surprised to find that it > supported Cake, and I set it up and tested using queue discipline as "cake" > and queue setup script "layer_cake.qos" I have been following the progress > over time in the bufferbloat email lists, but was not aware that I could > access a build supporting cake without doing my own build and I was not > really knowledgeable enough to take that on. > > I've so far been extremely pleased with the results of my initial testing, > and even when I set the bandwidth limit at very low speeds (like 1 Mbs up > and down), applications like Netflix worked perfectly, pings were great, and > dslreports.com/speedtest, report A+ on bufferbloat. My own query these days is how does it compare to htb + fq_codel? I am having trouble seeing any performance difference at all on the hardware I have under test. > As I read about the qos part, I am wondering however is it only IP Layer-3 > DSCP which goes into the queue management system or is Layer-2 traffic like > 802.1p traffic also being managed? No layer 2 stuff is handled. Sometimes that's impossible, it's not preserved when packets are routed. When things are bridged, it's often bypassing major portions of the stack. Now, if a wired to p2p wireless bridge existed that was sane to hack on, carrying some of that 802.1p traffic would help. my take generally has been on - if you must deal with 802.1p, re-mark the dscp value so it can survive transit across multiple links (and even then, it won't). > > It would be great to manage that as well if it is not because there are many > applications where there is bufferbloat which could be managed by OpenWRT. Managing bufferbloat is almost entirely independent of QoS markings. Controlling queue length and fair queuing are vastly more effective. > For example, there are wireless links between buildings, situations where > priority packets are not marked. Voip phones often are set by default to > prioritize voice packets via 802.1p. Sure. But it doesn't matter anywhere near as much as fq or queue length. the biggest problem linux wifi has currently is huge driver queues, that no amount of reprioritization can get through. > > Please let me know your thoughts on this. There are so many issues with wireless that it's hard to start. For starters, cake is the wrong thing for wireless. it (like fq_codel) would work ok if we had less buffering in general, but only on p2p links, and it would still behave badly with multicast and with interference. Fixing p2mp (e.g. Access points) is harder. I go into how we plan to try to tackle wireless issues here: https://www.youtube.com/watch?v=Rb-UnHDw02o I really should do a diagram of what people think happens when qos markings are used, vs what is actually happening, and nail it to the wall, like Luther. Gospel 'roun here is short queues with fq, first. Some of the algorithms and ideas in cake might get reused. Certainly the development experience and tests we've developed will.