From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3212821F38A for ; Mon, 22 Sep 2014 02:05:22 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MPDeK-1XRbqQ0zGy-004UWl; Mon, 22 Sep 2014 11:05:18 +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: Date: Mon, 22 Sep 2014 11:05:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00F904AB-F4DB-4FAB-84C3-F8374E3B11AF@gmx.de> References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> To: Billy Tallis X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ufMEtEm8BGqTKDYbWzB3s1ptfJRIOm6hlKRb2i/zmv96J97peSl m+W/2ID1zdmTNwHHFk5dxcL+GJvvu8RcM1MKjqU6QmxhMpnuRSG27sdty43oWRyylXwiB8C lOiWJvcJTvKnb+yngSdGLKoJsIvM2U162r3uKqxFJr4otMRKCDRtWVPTIoO504orzp2aB4Y 7K53f6dUZicHtY2f+eQ5Q== X-UI-Out-Filterresults: notjunk:1; Cc: "lartc@vger.kernel.org" , Andy Furniss , "cerowrt-devel@lists.bufferbloat.net" , Alan Goodman 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 09:05:51 -0000 Hi Bill, On Sep 21, 2014, at 23:18 , Billy Tallis wrote: > On my Linux boxes ping has a -A option for adaptive ping, effectively = sending out a new ping as soon as the reply to the last one is received, = instead of having to wait a fixed period of time between pings. Interesting, the current version of ping_sweeper sends a ping = every 10ms, with the typical RTT on a ADSL link > 10ms I am not sure how = much =93-A=94 speeds things up (except your method does work with any = uplink speed, while with fixed intervals one needs to tweak the ping = interval). One other reason for the ping interval was, that some = routers/BRAS/DSLAMs are rumored to rate limit ICMP processing so I = wanted to be able to control the rate to be able to work around such = limitations. > I modified ping_sweeper to use that last December when I was still on = a DSL link and was able to find the overhead with only a few minutes of = collecting data. (The connection was 6Mbps down, 512kbps up.) So, the slower the link is the fewer packed you need, as the per = ATM cell time increase gets larger and hence easier to detect in the = noise. xDSL uses a symbol rate of 4KHz, so there should be a = quantization of 0.25 ms caused that will make detection of fast uplinks = trickier (in my experience it works up to 2600Kbps the fastest I had = available)... > There was a bit of noise in the data from other traffic in the house, = but the stair-step shape of the plot was unmistakeable and the octave = script had no trouble identifying the per-packet overhead. Great to hear that is worked out. Best Regards Sebastian >=20 > 2014-09-21 14:35 GMT-04:00 Sebastian Moeller : > Hi Dave, hi Andy, >=20 >=20 >=20 > On Sep 20, 2014, at 19:55 , Dave Taht wrote: >=20 > > 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 >=20 > 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 ;) ) >=20 >=20 > Best Regards > Sebastian >=20 >=20 > > > > On Sat, Sep 20, 2014 at 7:17 PM, Andy Furniss = wrote: > >> Alan Goodman wrote: > >>> > >>> Hi, > >>> > >>> I am looking to figure out the most fool proof way to calculate = stab > >>> overheads for ADSL/VDSL connections. > >>> > >>> ppp0 Link encap:Point-to-Point Protocol inet = addr:81.149.38.69 > >>> P-t-P:81.139.160.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING = NOARP > >>> MULTICAST MTU:1492 Metric:1 RX packets:17368223 errors:0 = dropped:0 > >>> overruns:0 frame:0 TX packets:12040295 errors:0 dropped:0 = overruns:0 > >>> carrier:0 collisions:0 txqueuelen:100 RX bytes:17420109286 (16.2 = GiB) > >>> TX bytes:3611007028 (3.3 GiB) > >>> > >>> I am setting a longer txqueuelen as I am not currently using any = fair > >>> queuing (buffer bloat issues with sfq) > >> > >> > >> Whatever is txqlen is on ppp there is likely some other buffer = after it > >> - the default can hurt with eg, htb as if you don't add qdiscs to > >> classes it takes (last time I looked) its qlen from that. > >> > >> Sfq was only ever meant for bulk, so should really be in addition = to > >> some classification to separate interactive - I don't really get = the > > > > Hmm? sfq separates bulk from interactive pretty nicely. It tends to = do > > bad things to bulk as it doesn't manage queue length. > > > > A little bit of prioritization or deprioritization for some traffic = is > > helpful, but most traffic is hard to classify. > > > >> bufferbloat bit, you could make the default 128 limit lower if you = wanted. > > > > htb + fq_codel, if available, is the right thing here.... > > > > = http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die > > > >>> The connection is a BT Infinity FTTC VDSL connection synced at > >>> 80mbit/20mbit. The modem is connected directly to the ethernet = port > >>> on a server running a slightly tweaked HFSC setup that you folks > >>> helped me set up in July - back when I was on ADSL. I am still > >>> running pppoe I believe from my server. > >> > >> > >> I have similar since May 2013 and I still haven't got round to = reading > >> up on everything yet :-) > >> > >> I have extra geek score for using mini jumbos =3D running pppoe = with mtu > >> 1500 which works for me on plusnet. You need a recent pppd for this = and > >> a nic that works with mtu >=3D 1508. > >> > >> As for overheads, initial searching indicated that it's not easy or > >> maybe even truly possible like adsl. > >> > >>> The largest ping packet that I can fit out onto the wire is 1464 > >>> bytes: > >>> > >>> # ping -c 2 -s 1464 -M do google.com PING google.com = (31.55.166.216) > >>> 1464(1492) bytes of data. 1472 bytes from 31.55.166.216: = icmp_seq=3D1 > >>> ttl=3D58 time=3D11.7 ms 1472 bytes from 31.55.166.216: icmp_seq=3D2 = ttl=3D58 > >>> time=3D11.9 ms > >>> > >>> # ping -c 2 -s 1465 -M do google.com PING google.com = (31.55.166.212) > >>> 1465(1493) bytes of data. From > >>> host81-149-38-69.in-addr.btopenworld.com (81.149.38.69) icmp_seq=3D1= > >>> Frag needed and DF set (mtu =3D 1492) From > >>> host81-149-38-69.in-addr.btopenworld.com (81.149.38.69) icmp_seq=3D1= > >>> Frag needed and DF set (mtu =3D 1492) > >> > >> > >> You can't work out your overheads like this. > >> > >> On slow uplink adsl it was possible with ping to infer the fixed = part > >> but you needed to send loads of pings increasing in size and plot = the > >> best time for each to make a stepped graph. > >> > >> > >>> Based on this I believe overhead should be set to 28, however with = 28 > >>> set as my overhead and hfsc ls m2 20000kbit ul m2 20000kbit I seem > >>> to be loosing about 1.5mbit of upload... > >> > >> > >> Even if you could do things perfectly I would back off a few kbit = just > >> to be safe. Timers may be different or there may be OAM/Reporting = data > >> going up, albeit rarely. > >> > >>> > >>> No traffic manager enabled: > >>> > >>> = http://www.thinkbroadband.com/speedtest/results.html?id=3D1411160894248839= 90118 > >>> > >>> > >>> HFSC traffic manager: > >>> > >>> = http://www.thinkbroadband.com/speedtest/results.html?id=3D1411162166210931= 33034 > >>> > >>> > >>> > >>> Am I calculating overhead incorrectly? > >> > >> > >> VDSL doesn't use ATM I think the PTM it uses is 64/65 - so don't = specify > >> atm with stab. Unfortunately stab doesn't do 64/65. > >> > >> As for the fixed part - I am not sure, but roughly starting with IP = as > >> that's what tc sees on ppp (as opposed to ip + 14 on eth) > >> > >> IP > >> +8 for PPPOE > >> +14 for ethertype and macs > >> +4 because Openreach modem uses vlan > >> +2 CRC ?? > >> + "a few" 64/65 > >> > >> That's it for fixed - of course 64/65 adds another one for every 64 = TBH > >> I didn't get the precice detail from the spec and not having looked > >> recently I can't remember. > >> > >> BT Sin 498 does give some of this info and a couple of examples of > >> throughput for different frame sizes - but it's rounded to kbit = which > >> means I couldn't work out to the byte what the overheads were. > >> > >> Worse still VDSL can use link layer retransmits and the sin says = that > >> though currently (2013) not enabled, they would be in due course. I = have > >> no clue how these work. > >> > >> > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe lartc" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > -- > > Dave T=E4ht > > > > https://www.bufferbloat.net/projects/make-wifi-fast > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20