From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F080221F2C5 for ; Mon, 22 Sep 2014 03:01:34 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id fb4so2564104wid.15 for ; Mon, 22 Sep 2014 03:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dgy38PXCXM7s0FaHyO+L2/FBu6Vtss1RJCNP1ER0ro4=; b=ujPKjNi26DcsYZvqTLH6buae/KkUV41XyZkUzRPz7GO71AH/hRI10953oKzMATiQ1G edkxvzkSKAq6kysdCRbs1uuZVkBckrJ8XRAsdCoa2ehurAiHFDU9yaFdx+UdUeX8DPnG 1E21/tbzqqfsC4osflh0GxNAvDt5N9hSnTO2P+R0jq2bgc1p8VjtjfY9LhVhSRhJjuad cwbHEWTAGuzeaTmk+tuav43czYGm27qgLAgQNcYostlarA3Oj18Nkse6uZe+ePttkiW6 wxqHKk98w4cUNe1X+yNOEWFxbrrdIzbCxB+DD4pcqFzSCuFgtNLeQiLbDVTI/M76d668 c4sg== X-Received: by 10.180.210.239 with SMTP id mx15mr14427841wic.29.1411380092338; Mon, 22 Sep 2014 03:01:32 -0700 (PDT) Received: from [192.168.0.3] ([81.174.180.31]) by mx.google.com with ESMTPSA id ia3sm3355131wjb.12.2014.09.22.03.01.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 03:01:31 -0700 (PDT) Message-ID: <541FF37E.8080904@gmail.com> Date: Mon, 22 Sep 2014 11:01:34 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Sebastian Moeller , =?windows-1252?Q?Dave_T=E4ht?= References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> In-Reply-To: <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 22 Sep 2014 10:01:39 -0700 Cc: Alan Goodman , "cerowrt-devel@lists.bufferbloat.net" , "lartc@vger.kernel.org" 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:02:03 -0000 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… > > 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.