From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 469B721F324 for ; Tue, 23 Sep 2014 10:47:16 -0700 (PDT) Received: from hms-beagle.home.lan ([91.50.102.81]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M8edX-1YRs3K1MMl-00wBDo; Tue, 23 Sep 2014 19:47:09 +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: <54218D48.1020906@gmail.com> Date: Tue, 23 Sep 2014 19:47:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Andy Furniss X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:LNWUOikft6IVVS79/iOfZz/0288nUNCMUTfIALW4CTE7Lk4jPQa vlwIJRxobYLJUmqMs4pPwj2y0Evc3pj+RkjcUPMfhpjpXv4FaVKFRZDcHRxIQFSCLRcQo87 3GuhyliZ7AFG0l7gdRKxHF+2Jo/ZV33kQKAmcecwelkgDDvuGR3cXHDPYoENaAlk75lgxgc rfkjV53CnohYBWJ2/KUwA== 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: Tue, 23 Sep 2014 17:47:45 -0000 Hi Andy, On Sep 23, 2014, at 17:10 , Andy Furniss wrote: > Sebastian Moeller wrote: >=20 >> I would just go and account for all overheads I could deduce, so I >> would guess: 8 bytes PPPoE, 4 byte VLAN tags, 14 bytes ethernet >> header (note for tc=92s stab method one needs to include the ethernet >> headers in the specified overhead in spite of the man page) >=20 > I don't think the man page is wrong - it includes eth in the pppoe = example. I am not sure we are talking about the same man page then. =46rom = opens use 13.1 =93man tc-stab=94: When size table is consulted, and you're shaping traffic for the sake of = another modem/router, ethernet header (with- out padding) will already be added to initial packet's = length. You should compensate for that by subtracting 14 from the above overheads in such case. If you're shaping directly = on the router (for example, with speedtouch usb modem) using ppp daemon, you're using raw ip interface without = underlying layer2, so nothing will be added. For more thorough explanations, please see [1] and [2]. BUT if you look at the kernel code, stab does not automatically include = the ethernet overhead, so the subtract 14 in the above is actually = wrong. See http://lxr.free-electrons.com/source/net/sched/sch_api.c#L538 = where =93pkt_len =3D skb->len + stab->szopts.overhead; is used instead = of using =93qdisc_skb_cb(skb)->pkt_len=94 that as filled properly in = http://lxr.free-electrons.com/source/net/core/dev.c#L2705 . At least to = me this clearly looks like the ethernet overhead is not pre-added when = using stab, but I could be wrong.=20 And on an ADSL link you can see this quite well, with the proper = overhead values sqm-scripts still controls the latency under = netperf-wrapper=92s RRUL test nicely even if the shaping rate equals the = line rate, with the overhead to small latency goes down the drain ;) >=20 > There is a difference between shaping on ppp and shaping on eth which > needs to be and is noted. Again I am not sure about the validity of the information in the = man page... >=20 > FWIW I tried a few pings on my VDSL2 and don't think I'll be any use = for > results. Well for the overhead calculation my script absolutely requires = ATM cell quantization, with PTM as usual on VDSL2 it has no chance of = working at all; the =93signal=94 it is searching for simply does not = exist with a PTM carrier ;) >=20 > I do get an increase with larger packets but it's more than it should = be > :-(. If it is nicely linear that would be great. >=20 > The trouble is that my ISP does DPI/Ellacoya Qos for my ingress and I > guess this affects things a bit too much for sub milisecond accuracy > needed on a 20/80 line. Okay, so one issue is that with 80/20 you would expect the = RTT-difference if you add a single ASTM cell to your packet to be: ((53*8) / (80000 * 1000) + (53*8) / (20000 * 1000) ) * 1000 =3D = 0.0265milliseconds With ping typically only reporting milliseconds with 1 decimal point = this means even if you had an ATM carrier you would be in for a long = measurement train=85 but BT VDSL runs on PTM so even with weeks of = measurement time all that would show you is that there is no ATM = quantization ;) >=20 > At least I don't have to bother so much about ingress shaping (not = that > I would @80mbit so much anyway). I would a) love to have your connection, and b) would still try = to shape ingress; but currently not much affordable home routers can = actually reliably shape a 80/20 connection... >=20 > Ping and game traffic comes in tos marked 0x0a and gets prio on their > egress which is set slightly lower than my sync profile speed. Yeah, it seems excessively hard to calculate the net rate on = VDSL links as a number of encapsulation details are well hidden from the = end user (think DTU size=85) so simply aiming lower and perform a few = tests seems like the best approach. A bit of a pity since on ATM we = really could account for all (and for that reason I saw great latency = results even when shaping my line to 100% of reported line-rate). I am = quite curious how tricky this is going to be on VDSL... >=20 > Additionally it's probably not the best time to test as they had a > recent outage which caused in-balance on their gateways which seems to > still persist. >=20