From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 B926021F3A5 for ; Mon, 22 Sep 2014 03:20:24 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MEccf-1XXtL83iuH-00FlUF; Mon, 22 Sep 2014 12:20:17 +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: <541FF37E.8080904@gmail.com> Date: Mon, 22 Sep 2014 12:20:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> <541FF37E.8080904@gmail.com> To: Andy Furniss X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:1U9gyIbcCR8EE1FeyXkAlZ+4iNfbOrPtWYgvXl99xk+akaiBiHz CCz4mQMXFOx6DlKlLO9/wlp9gd8YFWO8yEjL35sapYhqNyuLMSj/l3RMvisfiqVfH3oDPm9 i1tVhHEbgfKs7buT0Bu/cA7Yv7WHkVw3onarPcNsfXPvdlXRR5DmcckeXseguzbK08dUjCu NtSSU/c+K1X27W4ZMqpSA== X-UI-Out-Filterresults: notjunk:1; Cc: "lartc@vger.kernel.org" , "cerowrt-devel@lists.bufferbloat.net" , Alan Goodman 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: Mon, 22 Sep 2014 10:20:53 -0000 Hi Andy, On Sep 22, 2014, at 12:01 , Andy Furniss wrote: > Sebastian Moeller wrote: >> Hi Dave, hi Andy, >>=20 >>=20 >>=20 >>=20 >> On Sep 20, 2014, at 19:55 , Dave Taht wrote: >>=20 >>> We'd had a very long thread on cerowrt-devel and in the end >>> sebastian (I think) had developed some scripts to exaustively (it >>> took hours) derive the right encapsulation frame size on a link. I >>> can't find the relevant link right now, ccing that list=85 >>=20 >> I am certainly not the first to have looked at ATM encapsulation >> effects on DSL-links, e.g. Jesper Dangaard Brouer wrote a thesis >> about this topic (see http://www.adsl-optimizer.dk) and together with >> Russel Stuart (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) One note about Russel=92s handy list of ADSL overheads, these do = not include VLAN tags so all the shown combinations can be 4 byte larger = if a clan tag is added, as is quite common nowadays for double- and = tripple play connections. Fun fact for a rather run of the mill = encapsulation with, LLC/SNAP over AAL5 with clan tbs we now have three = independent methods to multiplex different =93connections over the line=94= (and that does not count PPPoE), all provisioned out of the bandwidth = the end user pays for and best case is only one of the is functional, = but I digress... >> I believe they taught the linux kernel about how to account for >> encapsulation. What you need to tell the kernel is whether or not you >> have ATM encapsulation (ATM is weird in that each ip Packet gets >> chopped into 48 byte cells, with the last partially full cell padded) >> and the per packet overhead on your link. You can either get this >> information from your ISP and/or from the DSL-modem=92s information >> page, but both are not guaranteed to be available/useful. So I set >> out to empirically deduce this information from measurements on my >> own link. I naively started out with using ICMP echo requests as >> probes (as I easily could generate probe packets with different sizes >> with the linux/macosx ping binary), as it turned out, this works well >> enough, at least for relatively slow ADSL-links. So ping_sweeper6.sh >> (attached) is the program I use (on an otherwise idle link, typically >> over night) to collect ~1000 repetitions of time stamped ping packets >> spanning two (potential) ATM cells. I then use >> tc_stab_parameter_guide.m (a matlab/octave program) to read in the >> output of the ping_sweeper script and process the data. In short if >> the link runs ATM encapsulation the plot of the data needs to look >> like a stair with 48 byte step width, if it is just smoothly >> increasing the carrier is not ATM. For ATM links and only ATM links, >> the script also tries to figure out the per packet overhead which >> always worked well for me. (My home-link got recently a silent >> upgrade where the encapsulation changed from 40 bytes to 44 bytes >> (probably due to the introduction of VLAN tags), which caused some >> disturbances in link capacity measurements I was running at the time; >> so I ran my code again and lo and behold the overhead had increased, >> which caused the issues with the measurements, as after taking the >> real overhead into account the disturbances went away, but I guess I >> digress ;) ) >=20 > Sounds like a handy script, though I am not so sure it would help for > vdsl 64/65 (if that is actually used!). No, currently my script will tell you whether you have ATM cell = encapsulation on your link or not (as far as I know VDSL2 means PTM = (64/65), ADSL[1,2,2+] means ATM, not sure about VDSL1, but I think = neither is VDSL2 prohibited from using ATM nor is ADSL stuck on ATM). = If, and only if ATM is used will the script help to deduce the per = packet overhead. I am still waiting for the upgrade to VDSL2 on my home = link, once I have that available I will see whether I can figure out = information about the per packet overhead or not; all I know is that my = current approach will not work, because it relies on the ATM = quantization. > I don't think there is any > padding (but may be wrong!). No, according to the standard the 64/64 encapsulation is = =93continous=94, so not padded-out or reset for each packet >=20 > As for the history, Yea Jesper got his stuff in - but didn't allow > negative overheads so I still used to have to patch tc to workaround = that. True, but the =93stab=94 work for tc got this right. Also note = that the stab option does not automatically include the known overhead = to the packet as indicated by the outdated man-page, so that the ability = to specify negative overheads is basically not needed or useful. And yes = the kernel needs to be fixed, one of these days. Speaking of kernel = code, Jesper =93recently=94 hoisted HTB=92s link layer adjustment method = into the present (getting basically rid of the tables and allowing for = GRO packets), something that stab also needs to have fixed... >=20 > Before his work there was some user space code by IIRC Dan Singletary > which I used for a while and later Ed Wildgoose analysed the kernel = code > and posted patches for htb and tc on the original lartc list which I > used for some time before Jespers code got in. Interting piece of history, all that happened before I cared, = heck even Jespers thesis was out by then. Best Regards Sebastian >=20 >=20