From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Mon, 22 Sep 2014 10:01:34 +0000 Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections Message-Id: <541FF37E.8080904@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: > Hi Dave, hi Andy, > > > > > On Sep 20, 2014, at 19:55 , Dave Taht wrote: > >> 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 > > 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/) > 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 ;) ) Sounds like a handy script, though I am not so sure it would help for vdsl 64/65 (if that is actually used!). I don't think there is any padding (but may be wrong!). 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. 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.