Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections

[Andy Furniss <adf.lists@gmail.com>]

Sebastian Moeller wrote:
> Hi Dave, hi Andy,
>
>
>
>
> On Sep 20, 2014, at 19:55 , Dave Taht <dave.taht@gmail.com> 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…
>
> 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’s 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.