From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 27A69200236 for ; Fri, 10 Feb 2012 09:02:39 -0800 (PST) Received: by wibhm2 with SMTP id hm2so3513119wib.16 for ; Fri, 10 Feb 2012 09:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DXXi61gDE7l0QWQY6CQ4y+g2iRf1tMaOxw+PvYdTGPo=; b=tKr6EXst7JIB1sKZAkZmXyIFsFhjhH/emxjylm7VN/wDhm+BCJer6KcRsvWbpADSCC hOBqDS36riUwNzhsXmhvoezzcbnAOPpq9T9kX5iLzg9l8vv3TnpmkS2aelBlJRYCrbX0 VLSxO+MCncBTvTTvU3O+f12byRThgZ2dP06cA= MIME-Version: 1.0 Received: by 10.180.92.226 with SMTP id cp2mr10462431wib.10.1328893357325; Fri, 10 Feb 2012 09:02:37 -0800 (PST) Received: by 10.223.72.1 with HTTP; Fri, 10 Feb 2012 09:02:37 -0800 (PST) In-Reply-To: <1328891499.32007.7.camel@ovo> References: <1328891499.32007.7.camel@ovo> Date: Fri, 10 Feb 2012 17:02:37 +0000 Message-ID: From: Dave Taht To: Tobias Wolf , cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] question regarding OpenWrt vs. CeroWrt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 17:02:40 -0000 On Fri, Feb 10, 2012 at 4:31 PM, Tobias Wolf wrote: > Salve, > > I=92m just a random user of Openwrt that is not convinced that its > qos-scripts is doing a good job. I have a quick question. qos-scripts is fouling up pretty badly. > > I=92ve built OpenWrt trunk today and there was a commit mentioning your > name, so I googled you. I found the CeroWrt feature tracker where you > point out the defects of qos-scripts ("We can do better"). > > My question is, do you see possible medium-term fixes to qos-scripts to > be made to OpenWrt trunk, or does all this stuff have to cook for longer > in CeroWrt? I am not quite at the point to where I can effectively simulate or measure various workloads. I have to completely rebuild bloatlab #1, to do so, and that's in california. I'm trying to pull together enough spare cash to make that trip at a time that all the pieces now in loose formation have stablized enough for wider scale testing. I'm really reluctant to make any fixes at all to the qos-scripts until I can measure what they do currently effectively. Certainly I look at what they do for a 4Mbit upload system, and shudder, with 16000 buffers for one htb tier and a setting for red that looks to be utterly ineffective. http://www.bufferbloat.net/issues/331 > That is, do you see yourself fixing qos-scripts itself to at > least get a little better, or would an interested user have have to I do plan to improve qos-scripts in the form they are currently in. I am also building an alternate package (aqm-scripts) in the ceropackages repo and the cerowrt-luci repo that I hope one day could supplant it entirely. Regrettably the above requires patches to the 3.2 kernel (or 3.3) and an update to iproute2. So it is possible to move a version of openwrt ahead to take advantage of this stuff by applying several of the patches here: http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/ (some of which just landed in opewrt head this morning) But I note the 3.2 backport of BQL and related is currently specific to the ar71xx hardware (although it needent be) Is there a specific platform you'd like to be playing with? > adopt the full experimental bufferbloat stack? i.e. are there quick > fixes on the horizon (given Openwrt trunk)? There are multiple fixes on the horizon for openwrt trunk. 3.2 based kernels have an actually working version of RED in them. 3.3 based kernels have a version of SFQ that enqueues new flows at queue head (and also sfqred, and a few other cool things) Both of these features qos-scripts will take advantage automatically I have a grave concern that the new SFQ is actually 'too good' http://www.bufferbloat.net/issues/332 And hope to resolve that with eric, jesper, etc before 3.3 All that said, the calculations that qos-scripts perform result in really overlong buffer lengths, and don't appear to deal with ipv6 properly. The latter is easy to fix, the former is rather resistant to formuliac analysis. And there are side effects from both BQL and HTB that need to be accounted for, notably manipulating tx queue and tx ring depth 'right'. I have good values for 'Too D*** Big', and 'Too D*** small', but 'Just righ= t', or merely, 'Not horrible', are thus far elusive. > > thanks, > Tobias > > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net