From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AE4113B2A0 for ; Wed, 20 Jan 2016 07:07:05 -0500 (EST) Received: by mail-wm0-x231.google.com with SMTP id b14so25766976wmb.1 for ; Wed, 20 Jan 2016 04:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=3zzTI2+cMQlbrKENM5bc4K+UqN7FdboUmuWCTuo3C5c=; b=FJUBhj1dasdQ99bixIrna6WDreawfQTeK9Cec+6Upcq+ltR4Jurr6chZEh7Rl+jr/m VVry0dhRCTAbjw0nPEXu1WdUiWfF/Mef4FW9D+hmctTqd7dqzs7ECrhkZPbUzhllvWt/ 6yPguwWMYMAVUfK9vFapn9GPnx3pmunZ4rgOvlaTgwLxywqSeA69mPRwX2YK/sd/KbSS r3ifrEtOAifWza4dDp/mBr4r8cwPkUWrnXmhwqBfoA7PA17s8tti3gaAKtGMB7z7zcJr 3xJY9pjDiLCxPxFKdovtKkts0Nh6HLoA+J3V0RNQtiyi+Pm829w+NkSs+1Dzn8jB7SkI 5g0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3zzTI2+cMQlbrKENM5bc4K+UqN7FdboUmuWCTuo3C5c=; b=XlsbWqr6Z56y3oaj9lY52ByaHFhUYSB30Mp2ve8O34mi5MfLq4flxyAHosvEJnCsuP 6gCUazunSM9KMIo24bU9VqvzRfIizwuJJ0gEWr/B94E6KC9BdNxkW4cz25aGI0zoppaL Qmq0G7di6sGUzauzsS51YYjs3ppUtwI+wzLD+cWMGnkBJXuxFRmYvJjs5FC7xNDjNIGl LaK9VXMewj8BIwtyV3aeNynG5Zyx7DmqsMZ0WcfCQM9UaiTLPLT68zQa+K+7ayyDG9wX k4SkUC6eQOtXaRhMNKTVqEiRX4Iuae2coenZtgB1IJMutTrZurQiBq0Kk8VxC2VXu0l3 uk/w== X-Gm-Message-State: ALoCoQmEpIuL2HDzTxwNunngc104u6cxOFzIyx/DVpholJVoFRwDMUtc8Vl3ZuZUZYBJGT9EsSiDaxR5NeYkm9AIslmLEd78FA== X-Received: by 10.194.201.134 with SMTP id ka6mr35982158wjc.116.1453291622037; Wed, 20 Jan 2016 04:07:02 -0800 (PST) Received: from [172.16.9.243] (host-92-31-2-189.as13285.net. [92.31.2.189]) by smtp.googlemail.com with ESMTPSA id 198sm24881443wml.22.2016.01.20.04.07.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 04:07:01 -0800 (PST) To: moeller0 References: <9A63607E-6B33-4084-91D6-E8727EBF2B67@gmx.de> Cc: Brandon Applegate , Bloat@lists.bufferbloat.net From: Alan Jenkins Message-ID: <569F785F.5010801@gmail.com> Date: Wed, 20 Jan 2016 12:06:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <9A63607E-6B33-4084-91D6-E8727EBF2B67@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] Getting started with sqm-scripts - latency good, bandwidth decimated X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 12:07:05 -0000 On 20/01/16 11:43, moeller0 wrote: >> On Jan 20, 2016, at 11:12 , Alan Jenkins wrote: >> >> On 19/01/2016, Brandon Applegate wrote: >>> Disclaimer: if this is the wrong list for such a question - let me know. >>> This is specifically about the sqm-scripts package... >>> >>> Hello, >>> >>> I’ve been reading all I can on the bufferbloat website and also trying to >>> understand the evolution of the various scripts (debloat, sqm, etc). >>> >>> I managed to get sqm-scripts on my firewall (Ubuntu linux on a PC - no *wrt >>> etc). Got it built with the ‘linux’ platform. Since this is Ubuntu 12.04 - >>> I had to cheat a bit and pull down the iproute2 source from 14.04. I’ve >>> tweaked the main sqm script to reflect this for the tc bindary - this is >>> working. I also updated my kernel to a later version that supports >>> fq_codel. >>> >>> My topology is ‘on a stick’. I have one gig interface to a managed switch, >>> on which are eth0.666 (outside/wan) and eth0.10 (inside). >>> >>> I have 30/5 cable service, and have tried both those values as well as 90% >>> in my /etc/sqm/*conf file. >>> >>> I’ve tried both eth0 (raw/parent interface) as well as eth0.666. >>> >>> No matter what I do - my bandwidth is 10% of what it should be. I get >>> approx. 3/4mbit down + 2/3mbit up on dslreports speedtest. Bufferbloat >>> looks great though - A+. >>> >>> Is there something inherent I’m doing wrong ? Something to do with my ‘on a >>> stick’ topology biting me ? Kernel version (Ubuntu’s 3.13.0-74-generic >>> btw). >>> >>> Thanks in advance for any help or info (or pointer to a more appropriate >>> list). >> It doesn't sound like you're doing anything wrong :(. >> >> I would make sure to check the rates on `tc class show dev eth0.666` >> (and ifb4eth0.666). Switching to `simplest.qos` could be easier to >> debug. With your simple.qos, there'll be several tracffic classes... >> the `root` should be the specified `rate`, and it looks like all >> classes save 1:11 should have a `ceil` just under the specified rate. >> >> Not sure how to debug qos-scripts itself. However the Gentoo wiki has >> a 50-line script, which was corrected by dtaht :). Like simplest.qos >> this has a single class. >> https://wiki.gentoo.org/wiki/Traffic_shaping >> >> That would let you investigate the commands finely, as well as the >> resulting state shown by `tc qdisc` and `tc class`, and really narrow >> it down. >> >> `dslreports.com` will show bandwidth and latency-under-load in each >> direction independently, so you could work on a single direction. I >> would look at ingress only (the IFB) since that's where your bandwidth >> decimation is so visible. E.g. just comment out the egress section, >> to avoid distractions. > It should be sufficient to set the egress rate to 0 then, as for sqm zero denotes no shaping and not a rate of zero kbps (good luck using TCP on a purely unidirectional link...) > >> I think you can run the htb without the fq_codel command at the end - >> that is, it will default to a massive fifo, which will replace the >> fq_codel in the output of `tc qdisc`, but to a first approximation it >> will affect bandwidth. > Simply put > QDISC=pfifo_fast > into the .conf file for eth0.666 to test this. > > Best Regards > Sebastian No offense to your work on sqm-scripts. 1) It's just in case the problem is *outside* of sqm-scripts, it could be useful to try the minimum commands necessary to demonstrate the problem. Maybe it's unfair but I assumed running on a PC is also a less tested case, as well as the "firewall on a stick" part. Equally, since AFAICT Brandon hasn't had a working AQM setup on this box before. It could be useful if the Gentoo script works, to prove that AQM + fq_codel can work correctly on Brandon's box. If the Gentoo script _wasn't_ working, that's when I'd suggest tearing it down e.g. to eliminate fq_codel as an issue. Rather than specify fifo explicitly, just don't run the fq_codel command (assuming that actually does something sensible, which can be checked using `tc qdisc`). 2) More specifically, you didn't mention trying "simplest.qos". This would i) simplify the setup we're trying to debug, and ii) it might show if there's a bug with the more complex bandwidth calculations / assignments in "simple.qos". And again - I suggest starting by checking `tc class show dev eth0.666`, because it's not a 100% obvious command, and we don't want to miss if there are bad rates there :). Alan