From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 24 Sep 2014 09:17:52 +0000 Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections Message-Id: <54228C40.4050605@gmail.com> List-Id: References: <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> In-Reply-To: <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org 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=3Dqdisc_pkt_len_init (line > 2731): > > qdisc_skb_cb(skb)->pkt_len +=3D (gso_segs - 1) * hdr_len ; > > 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. 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=85 (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=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. 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 =3D ip len On eth skb->len =3D ip len + 14 On vlan skb->len =3D 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.