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-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A497F21F391 for ; Wed, 24 Sep 2014 09:23:43 -0700 (PDT) Received: from u-089-cab203a2.am1.uni-tuebingen.de ([134.2.89.4]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0McEkx-1XpBqm3tId-00JYBT; Wed, 24 Sep 2014 18:23:40 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <54228C40.4050605@gmail.com> Date: Wed, 24 Sep 2014 18:23:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16C372C8-70C4-4E62-A059-BF2C65A88CF0@gmx.de> References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> <54201F8B.70408@yescomputersolutions.com> <3136C05A-8069-4F04-B352-69A2BF3578FC@gmx.de> <5420AAA1.70203@yescomputersolutions.com> <54218D48.1020906@gmail.com> <5421C490.3020104@gmail.com> <54228C40.4050605@gmail.com> To: Andy Furniss X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:TZ9BnMvz5EFqTZ+Gyu0bsyyuldTEznMKlsE/Dzu2n3Zp9GITGQ7 Jy4CD5vuqacbJJCpnE/vhnlPbjFMfREcO+fzhfH+uin8U3+jGF91Zz4ROk8vx+Pc8T3PeKR fzO5sJ1VQ1Bfal7DYVWVU1u0i2NV4B4zRz0HV00iqXPXK9wl06Go8x1GA2n+LMvpy09tiPQ JEsaNm2t43YkYUzHdps6Q== X-UI-Out-Filterresults: notjunk:1; Cc: "lartc@vger.kernel.org" , Alan Goodman , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections 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: Wed, 24 Sep 2014 16:24:12 -0000 Hi Andy, On Sep 24, 2014, at 11:17 , Andy Furniss wrote: > Sebastian Moeller wrote: >=20 >> Thanks for sharing your test case; I can repeat these results >> exactly on my machines (I also tried htb instead hfsc for fun: same >> result as to be expected see below). Looking back at >> http://lxr.free-electrons.com/ident?i=3Dqdisc_pkt_len_init (line >> 2731): >>=20 >> qdisc_skb_cb(skb)->pkt_len +=3D (gso_segs - 1) * hdr_len ; >>=20 >> I begin to realize this function is not responsible for adding >> single wire packet=92s ethernet header, but for figuring out in how >> many on-the-wire packets to chop down a GSO packet , and add the >> header overhead for the additional wire packets, I had completely >> looked over the (gso-segs - 1) part, oops. >=20 > Glad it helped - I know from trying, and giving up, how hard/error = prone > reading kernel code can be :-) Especially when all one knows about C is basically from reading = K&R with almost no hands-on coding experience ;) >=20 >>=20 >> @cerowrt-devel: everyone using link layer ATM you might want to try >> to reduce the the per packet overhead by 14=85 (but please test) >=20 > Maybe you mean overhead calculated by a script? Well in cerowrt=92s SQM-scripts we expose the stab options so = users can take link layer and overhead into account. If you naively = determine the overhead, either with the help of the scrips I posted = earlier or by looking it up on a table (if the encapsulation options are = known) you will end up not handling the kernel=92s auto-added overhead = well. Currently SQM scripts does not expose PPP devices only ge00 = (ethernet) so -14 seems currently the best recommendation in combination = with =93please test=94. What I am curious after your message is what = happens if the kernel terminates a pppoe connection but is connected to = a =93modem=94 via ethernet, what does the kernel do. And thanks to your = pointers I know have an idea of how to test that ;) >=20 > Just to be clear, I expect that wrt would be shaping on ppp, so you > don't need to take 14 if that's the case. Good to know. >=20 >=20 >> So I stand corrected, you are right, tic=92s stab automatically adds >> the ethernet header. So I am off to repeat my netperf-wrapper tests >> right now again with overhead of 30 instead of 44, again these tests >> confirm your observation. Interestingly, it seems netperf-wrapper=92s >> RRUL test really is suited to figure out the overhead: while shaping >> to 100% of line rate (on ADSL2+ where line rate rate is the net line >> rate (after FEC)) specifying too small an overhead the ICMP latency >> plot shows larger deviations from the expected unload RTT plus 10ms. >> Too large an overhead however just decreases the good put bait while >> leaving the latency well under control. >=20 > I wouldn't word it like "stab adds ..." This is nothing to do with = stab > really - just the only length stab knows is skb->len and that means > different things on different interfaces because of how the kernel = works. >=20 > (I haven't retested all this, but I doubt it's changed) >=20 > On ppp skb->len =3D ip len >=20 > On eth skb->len =3D ip len + 14 >=20 > On vlan skb->len =3D ip len + 18 So this is the information I actually wanted to find and then = somehow thought qdisc_pkt_len_init() was the place. Do you by chance = have any pointer where this assignment is handled? >=20 > If you ran my script on various interfaces without stab I expect you > would still be able to see the difference - everyone who does any tc = on > eth gets shaping with ip+14 sized packets. >=20 > Even without tc involved I think you could see the difference looking = at > ip -s ls xxxx type stats on different interfaces. Thanks again, & Best Regards Sebastian >=20