From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 B2B5821F2E4 for ; Wed, 24 Sep 2014 02:17:51 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so2641126wgg.7 for ; Wed, 24 Sep 2014 02:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=s8bIFrIS3ckvVt0wgbleQkRf2yGTlu2WllA98kVy59o=; b=l3O+Ia9o+SUrTFEvHDwPYawHtbmkmL4t2/F+BdmX3J4NFKXDEEBdGBRSiSKzgeDk3s f/VIZAd98vuGCaLEeFxTLjl1oW8dvW7L8nl2MYNDMbGlwat64z9DxyarFOn9yen0sDnL 69dCsmFnOn7T3fCnlYZXMWP1DEeMAWCE8WwPXu2vMY0HeJR2777vlj+EgNvjBRzPJt9X vEaYZVil+R4j/c8h7rYArZBzCWX9W26TT+zv/dAcGSTXzVdoq7nqx8vyHCNKxJWfPkt5 yrUFNDfGgkPbaewSI8aHa+IfGns1+oCfmGs6lX+DWLpWdwAUSbD7fzlZqS8Q+Cp1usin h2Qg== X-Received: by 10.194.204.232 with SMTP id lb8mr6852874wjc.0.1411550269619; Wed, 24 Sep 2014 02:17:49 -0700 (PDT) Received: from [192.168.0.3] (27.24.189.80.dyn.plus.net. [80.189.24.27]) by mx.google.com with ESMTPSA id cz3sm18723780wjb.23.2014.09.24.02.17.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Sep 2014 02:17:49 -0700 (PDT) Message-ID: <54228C40.4050605@gmail.com> Date: Wed, 24 Sep 2014 10:17:52 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Sebastian Moeller 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 09:18:21 -0000 Sebastian Moeller wrote: > 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=qdisc_pkt_len_init (line > 2731): > > qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len ; > > I begin to realize this function is not responsible for adding > single wire packet’s 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. Glad it helped - I know from trying, and giving up, how hard/error prone reading kernel code can be :-) > > @cerowrt-devel: everyone using link layer ATM you might want to try > to reduce the the per packet overhead by 14… (but please test) Maybe you mean overhead calculated by a script? 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. > So I stand corrected, you are right, tic’s 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’s > 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. 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. (I haven't retested all this, but I doubt it's changed) On ppp skb->len = ip len On eth skb->len = ip len + 14 On vlan skb->len = ip len + 18 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. Even without tc involved I think you could see the difference looking at ip -s ls xxxx type stats on different interfaces.