From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0404E21F1FE for ; Fri, 23 Aug 2013 12:51:29 -0700 (PDT) Received: from hms-beagle-2.home.lan ([79.229.225.62]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MRGTX-1VdeXQ0iqd-00UZ6W for ; Fri, 23 Aug 2013 21:51:27 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sebastian Moeller In-Reply-To: <20130823092702.3171b5fd@redhat.com> Date: Fri, 23 Aug 2013 21:51:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33429532-7F55-4249-8E22-9E04B790D2BE@gmx.de> References: <56B261F1-2277-457C-9A38-FAB89818288F@gmx.de> <2148E2EF-A119-4499-BAC1-7E647C53F077@gmx.de> <03951E31-8F11-4FB8-9558-29EAAE3DAE4D@gmx.de> <20130823092702.3171b5fd@redhat.com> To: Jesper Dangaard Brouer X-Mailer: Apple Mail (2.1508) X-Provags-ID: V03:K0:9xSvDLaqOUJwh2Csn4O3WPJgoRy7HLgqrC71LZKo1bH0lanAgO5 4DlIQyht6/n1YvQleC4J5ThrnvQHjfw/QOW8JCnshk6OpeKj3ckxEMIeq2p9jKRb1SgATG3 HWCPc8J53jLK6W9m4Z6c3SWbcCHr7FQK+txwqUOdPCqnpcTMvyMp4gQa3cTmMJObdJmYQRO NAh7si4N6VxPKKl2k8YmA== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] some kernel updates 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, 23 Aug 2013 19:51:30 -0000 Hi Jesper hi List, On Aug 23, 2013, at 09:27 , Jesper Dangaard Brouer = wrote: > On Thu, 22 Aug 2013 22:13:52 -0700 > Dave Taht wrote: >=20 >> On Thu, Aug 22, 2013 at 5:52 PM, Sebastian Moeller = wrote: >>=20 >>> Hi List, hi Jesper, >>>=20 >>> So I tested 3.10.9-1 to assess the status of the HTB atm link layer >>> adjustments to see whether the recent changes resurrected this = feature. >>> Unfortunately the htb_private link layer adjustments still is >>> broken (RRUL ping RTT against Toke's netperf host in Germany of = ~80ms, same >>> as without link layer adjustments). On the bright side the tc_stab = method >>> still works as well as before (ping RTT around 40ms). >>> I would like to humbly propose to use the tc stab method in >>> cerowrt to perform ATM link layer adjustments as default. To repeat = myself, >>> simply telling the kernel a lie about the packet size seems more = robust >>> than fudging HTB's rate tables. >=20 > After the (regression) commit 56b765b79 ("htb: improved accuracy at > high rates"), the kernel no-longer uses the rate tables. =20 >=20 > My commit 8a8e3d84b1719 (net_sched: restore "linklayer atm" handling), > does the ATM cell overhead calculation directly on the packet length, > see psched_l2t_ns() doing (DIV_ROUND_UP(len,48)*53). > Thus, the cell calc should actually be more precise now.... but see = below >=20 >>> Especially since the kernel already fudges >>> the packet size to account for the ethernet header and then some, so = this >>> path should receive more scrutiny by virtue of having more users? >=20 > As you mention, the default kernel path (not tc stab) fudges the = packet > size for Ethernet headers, AND I made a mistake (back in approx 2006, > sorry) that the "overhead" cannot be a negative number. Meaning that > some ATM encap overheads simply cannot be configured correctly (as you > need to subtract the ethernet header). (And its quite problematic to > change the kABI to allow for a negative overhead) >=20 > Perhaps we should change to use "tc stab" for this reason. But I'm = not > sure "stab" does the right thing either, and its accuracy is also > limited as its actually also table based. We could easily change the > kernel to perform the ATM cell overhead calc inside "stab", and we > should also fix the GSO packet overhead problem. > (for now remember to disable GSO packets when shaping) >=20 >> It's my hope that the atm code works but is misconfigured. You can = output >> the tc commands by overriding the TC variable with TC=3D"echo tc" and = paste >> here. >=20 > I also hope is a misconfig. Please show us the config/script. I guess you nailed it. While I got no output whatsoever from = echo "func __detect_linklayer +p" = /sys/kernel/debug/dynamic_debug/control. I also followed Dave's advise = to dump the tc commands to file (see earlier mail). I turns out that the = script only added the HTB link layer adjustments to egress and not to = ingress as well, fixing that pushed the ping RTT for ht.'s link layer = adjustemtes (at 95% of linerate) down to ~45ms which is close enough to = what stab delivers. >=20 > I would appreciate a link to the scripts you are using... perhaps a = git tree? >=20 >=20 >>> Now, I have been testing this using Dave's most recent = cerowrt >>> alpha version with a 3.10.9 kernel on mips hardware, I think this = kernel >>> should contain all htb fixes including commit 8a8e3d84b17 = (net_sched: >>> restore "linklayer atm" handling) but am not fully sure. >>>=20 >>=20 >> It does. >=20 > It have not hit the stable tree yet, but DaveM promised he would pass = it along. >=20 > It does seem Dave Taht have my patch applied: > = http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/685-net_sched-re= store-linklayer-atm-handling.patch >=20 >>> While I am not able to build kernels, it seems that I am able to = quickly >>> test whether link layer adjustments work or not. SO aim happy to = help where >>> I can :) >=20 > So, what is you setup lab, that allow you to test this quickly? >=20 >=20 > --=20 > Best regards, > Jesper Dangaard Brouer > MSc.CS, Sr. Network Kernel Developer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer