Sebastian Moeller wrote:
Hi Dave, hi Andy,
On Sep 20, 2014, at 19:55 , Dave Taht <dave.taht@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
