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 B4B3221F340 for ; Tue, 23 Sep 2014 02:33:06 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ln8gj-1YD5oG1vRt-00hQAX; Tue, 23 Sep 2014 11:32:59 +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: <5420AAA1.70203@yescomputersolutions.com> Date: Tue, 23 Sep 2014 11:32:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> <54201F8B.70408@yescomputersolutions.com> <3136C05A-8069-4F04-B352-69A2BF3578FC@gmx.de> <5420AAA1.70203@yescomputersolutions.com> To: Alan Goodman X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:xndU5AezI8nahpz9AhKH4V9q/wSs8OIzfrKwkRnNUNn6X2ox8O7 9vxyMt/wvSjjHsJEagDHptPqdTvmHW/NO7xc015TP8qTn+oWPjxSpfuOghZ0f/skcmTKll7 CM17ftW1K6Tv8qVluAR84G/51oY8fdoyYHa1uoq9A5OzkUDMh+Og5hr4Js8fzimQnG0wTrv RDqYeeNGDUZEBIwUC5X0w== X-UI-Out-Filterresults: notjunk:1; Cc: Andy Furniss , "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: Tue, 23 Sep 2014 09:33:35 -0000 H Alan, On Sep 23, 2014, at 01:02 , Alan Goodman = wrote: > On 22/09/14 20:52, Sebastian Moeller wrote: >>> >This test was ran on a BT Infinity VDSL/FTTC connection with the = modem plugged directly into a CentOS 6 machine which is doing PPPoE. = The connection is synced at 80mbit down and 20mbit up. BT restrict = downstream speed to 77.44Mbps IP traffic. >> Thank you very much this is the first data set on a VDSL line I = have seen, and clearly me hypothesis that overhead detection on PTM = carriers will not work with the current code is nicely demonstrated. I = need to ponder this a bit more and I might not be able to find a nice = solution for those links... >=20 > You're welcome. If you need any more data feel free to drop me a = line. Thanks for the offer, I might take you up on it ;) (next month I = hope to upgrade to VDSL2 so I have an easier time trying new = methods...) >=20 >>>> I can run the test on a slower BT connection over the week end if = anyone is interested in the results? >> I would love to see that especially if the other connection is much = slower, as I see two possible issues with this data set: >=20 > The other connection is actually ADSL2, we probably know what the = results there will be=85 I assume that this will work reasonably well, for all adel lines = I tested 1000 samples per ping size and a range from 16 to 116 worked = out well enough to detect quantization and overhead. > I think I shall run the test on a really slow ADSL connection later = in the year to double check my overheads though. I think it is a decent idea to re-check the encapsulation used = occasionally, in my case the ISP added VLAN tags (which I neither need = nor want) increasing the overhead from 40 bytes to 44 bytes. If that had = not caused irregularities in the netperf-wrapper tests I run I would = probably not have noted. (If the link is fully saturated the wrong = overhead has a strong effect on the link=92s latency, but with moderate = load that is somewhat hidden so easy to overlook) > It seems like a very useful tool. Glad you like it ;) (I think the idea and method is sound, but = those I lifted from Jesper=92s thesis, my implementation however is = messy) >=20 > Also thanks for providing some example plots of how it should look. = That will allow me to better interpret results in future. >=20 >> 1) Speed: It might be that your line is fast enough to hide the ATM = quantization below another quantization (like the 4KHz symbol rate of = the individual carriers) or two many concurrent carriers;) >=20 > Would it be useful if I limited my upload speed with say hfsc to 1mbit = and re-ran the test? First I would try against different hosts, the fact that there = is no linear increase of the RTT with increasing packet size is a sign = that something is messing with our probe packets and hence the whole = thing gets iffy. BUT, I strongly assume your VDSL link is using packet transfer mode = (PTM) not ATM and so all my code can show you is that there is no = quantization, and since overhead detection currently requires ATM cell = quantization the reported numbers are just not useful. The reason to = still report these is that I have not determined a proper statistical = test to classify the link carrier. Note (I might have explained that earlier, but I am not sure = whether that was in this thread): the code tries to find packet sizes at = which the RTT increases, or in other words the boundaries of the ATM = cells. Once this is done it uses all information it has about = pre-payload overhead (ICMP header, IP header=85) and finds out how many = bytes are missing to fully fill the first (two) ATM cells (these cells = are not really shown in the plots), it then reports the previously = un-known pre-IP bytes as overhead that needs to be accounted for. >=20 > Given the above comments in Sebastian=92s very useful emails how would = it be best to shape these FTTC connections at present? So > Without overhead set or something else? I would just go and account for all overheads I could deduce, so = I would guess: 8 bytes PPPoE, 4 byte VLAN tags, 14 bytes ethernet header = (note for tc=92s stab method one needs to include the ethernet headers = in the specified overhead in spite of the man page), I am uncertain = about the 4 byte ethernet frame check sequence (it was typically not = included on ATM links). So in total 26 bytes; I would specify those, for = PTM getting the overhead wrong is not as bad as with ATM so just try to = make a good approximation.=20 A trickier question is how to select the shaping rate. In theory = all xDSL-modem report some sort of line rates, but unfortunately the = standards contain quite a lot slightly different rates the modem = manufacturer might decide to report, so guess the best one can do is to = guess, then iterate over measure and refine cycles to figure out the = =93optimal=94 shaping rates. Rich Brown=92s betterspeedtest.sh or = netperf-wrapper=92s RRUL test (see = http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloa= t/ ) are decent ways for the measure part=85 Best Regards Sebastian Moeller >=20 > Alan