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-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C59E221F1C7 for ; Sat, 28 Dec 2013 23:37:09 -0800 (PST) Received: from [192.168.2.41] ([79.202.2.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpsmR-1VHVKP2bnr-00fifp for ; Sun, 29 Dec 2013 08:37:07 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <3AE6C690-F53C-471F-9980-9E071B87D983@gmail.com> References: <3AE6C690-F53C-471F-9980-9E071B87D983@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Sun, 29 Dec 2013 08:36:57 +0100 To: Rich Brown , cerowrt-devel Message-ID: <41ec2fd6-4fb8-4e17-8458-861e27c2c5ff@email.android.com> X-Provags-ID: V03:K0:T6VnP9aEPc+IxS4atlzAEdIKeFGRxpu6FzSZUQIyJDx/5fAl8e0 hy2QJcusCI2CAaa5+fFisKB47oMggYZX+oRdSl29eEco4IMAkGU2MK8rzq6L3rZcEAzYX0V SUx3OkQpDQdRtljwZLhwjKaIkMqKI0OHX9UjZLE/3Ts9as4MenF/vauc2bR5lb5aVuyLJA9 Sk8FWuZ8eTHeyIV3bWvOg== Subject: Re: [Cerowrt-devel] SQM Question #2: How does CeroWrt use info gleaned from the link layer adaptation? 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: Sun, 29 Dec 2013 07:37:10 -0000 Rich Brown wrote: >QUESTION #2: How does CeroWrt use info gleaned from the link layer >adaptation? The link layer adaptations work in correcting the kernels estimate o= f a packets behavior on the wire=2E In the tc_stab case the kernel calculat= es the effective size of the packet on the wire, that is it pretends the pa= cket is larger than it really is, so for a given bandwidth it estimates the= correct time it takes for that packet to be actually transmitted=2E In the= htb_private case the kernel keeps the packet's size (more or less) intact = but adjusts its estimate of the packets transmit rate=2E Both methods boil = down to the same idea, make sure the packet scheduler will only send packet= N+1 after packet N has just cleared the wire=2E > >Specifically, the link layer adaptation all seem to be designed to >compute the actual time it takes to transmit a packet, accounting for >Ethernet & PPPoE header bytes, other overhead, and ATM 48-in-53 >framing=2E And the annoying size dependent padding of the last ATM cell=2E > >How does CeroWrt use this time calculation? Does it simply make sure >that the target time doesn=E2=80=99t get too low for a particular flow=E2= =80=99s queue? Thanks to the link layer adjustments (lla) cero now estimates the = correct time each packet takes and will not send any faster than the shaped= rate allows=2E If no lla is performed cero would overestimate the link cap= acity, send more than expected and potentially fill the modems bloated buff= ers=2E Traditionally people tried to reduce their shaped rate by >10% to at= least account for the 48 in 53 framing, but failed miserably for small pac= kets since overhead and padding can more than double the wire size of a pac= ket=2E Note that ACQ packets typically are small as are voice over IP packe= ts=2E I hope this helps Sebastian >(I could imagine that a short packet over ATM would take 2x the (naive) >expected/calculated time for a packet of that length, and that flow >would be penalized=2E Is there more to it?) >_______________________________________________ >Cerowrt-devel mailing list >Cerowrt-devel@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel Hi Rich --=20 Sent from my Android phone with K-9 Mail=2E Please excuse my brevity=2E