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.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B90943B29F for ; Tue, 4 Oct 2016 07:54:16 -0400 (EDT) Received: from [172.17.3.48] ([134.76.241.253]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MO7ee-1bo4uo3uU8-005bg5; Tue, 04 Oct 2016 13:54:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Tue, 4 Oct 2016 13:54:14 +0200 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <0B21E94A-EEF5-44A4-A6C8-1653BC983246@gmx.de> References: <66438228-D13A-42C4-8B42-11C49E0B2587@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:2aDEnZDsxNgMoU8SVKU5JFzFRvaNFIxXZLX6eVqKh8xu2pakc6x /PgNTuLrLkUwLbwu8wtKicSeMqElxDSnIzM0i5nKw9d9HXNiQuvxchjkbtmwJc7VIKAmyLh kA2LYVX5HjpIipFADHwxgBLexiV3uoaxhk66T4+ix7uG0Ki+RP4ilFQF0wf675is1CYAEDz rzUCBVh6xzGnJ0AwSOR7w== X-UI-Out-Filterresults: notjunk:1;V01:K0:vbNxOhFVbgU=:JEEKU1aIN0CSpw5sLCKxc+ Ju6ohZL/tywOQB8NvpOqJFAdB60hivwghjyrV/r0NmfhMURqrWvAkRWuWEP0cZp4E4VS0+rZt lVBfdviUXbxW9qpaGIE7Wy6V7J8+7vyABrptuPI+st+sm4ppYT8WAr3pSUMpWKJx9vO+HDfmJ idLEaJ3rLiUryg2kis36N7he+bWMF8GVIJUDPYW+IQcl12wZFj6m6IlE/EnUbaf04y6lhmjG3 GzhqJ7mvvq5j6ddJ2iRTzmae4AQLOcUD8S5Vvu9Sa1wyU5O/TltX4ZMcHaC6y+ZhDHzKwuZDG KwybTXMR3S3RGwS2U65i4AaucMwMW7Fiu3JDfW/RKRWLhSXotMqeHMr7qFj/UQaNT6Rdqx+mB qVIA6vX8zuCOHHM9WLlUO2GvcKXuJDzB60sY2m7LhYAf9HYlwTZq8gltcCKll7swjVTrO5Jp5 OsKFB98DLLvqAXEMfzfLqrPlJNEO7jZXCueF6HWNhRuJa5GIMjob/V9oh15sME7klX/U+lysB bGXE5QHbW3qIX9mXe//7VYd8nrP1WVsIxUTVJsngbhz6IpsARXsAI3CrmywgAeJIEDmnXegQe pvoyDqT0KPZI1D6OikmTmBujBRBrTKYoumymAz2tgEThCquiTYKyX6EVFnk4bGvLuA86HJ8sW eQxXgzj4RPGdBXsC357qfofuwR37qb3I2P5/h41VG7KfEp9YTQtqleJoEyDu9auumyxl0sqqB FyCB5cQ0VqDbeaI+1KIvMBsodLqdtnirFQMWcmP2czpqoU+Rd2BCGppCxpJV67U/4s7CY0oNg UvYTJ0n Subject: Re: [Cake] Master branch updated X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 11:54:17 -0000 Hi Jonathan, > On Oct 4, 2016, at 13:18 , Jonathan Morton = wrote: >=20 >=20 >> On 4 Oct, 2016, at 11:46, moeller0 wrote: >>=20 >> About that PTM accounting, could you explain why you want to perform = the adjustment as a a =E2=80=9Cvirtual=E2=80=9D size increase per packet = instead of a =E2=80=9Cvirtual=E2=80=9D rate reduction? >=20 > The shaper works by calculating the time occupied by each packet on = the wire, and advancing a virtual clock in step with a continuous stream = of packets. >=20 > The time occupation, in turn, is calculated as the number of bytes = which appear on the wire divided by the number of bytes that wire can = pass per second. As an optimisation, the division is turned into a = multiplication by the reciprocal. Okay, but that seems not really relevant to the topic at hand as = in PTM systems the effective payload-rate is 64/65 of the raw bit rate. = The 65th byte is independent of the actual packet size sent so = theoretically better modeled as a rate reduction than as a size = increase, even though in essence for a shaper you can account for it = either way. >=20 > I=E2=80=99m quite keen to keep the =E2=80=9Cbytes per second=E2=80=9D = purely derived from the raw bitrate of the link, because that is the = value widely advertised by ISPs and network equipment manufacturers = everywhere. Hence, overhead compensation is implemented purely by = increasing the accounted size of the packets. Sorry that does not make much sense, I realize that = mathematically they are interchangeable, but that does not make them the = same IMHO. Per packet overhead needs to be accounted on a per-packet = basis you have no other real option (unless you work with a fixed packet = length), but generic rate reductions do not need to be recomputed for = each packet. >=20 > I have been careful here to calculate ceil(len * 65/64) here, so that = the overhead is never underestimated. Which is Jonathanese for might be overestimated, so you at least = agree with my point about the precision of the accounting being = relevant. As I proposed in on of my comments =E2=80=9Cfloor(shaper_rate = * 64/64)=E2=80=9D has the same property of being conservative, only with = a lower possible error. > For example, a 1500-byte IP packet becomes 1519 with bridged PTM or = 1527 with PPPoE over PTM, before the PTM calculation itself. These both = round up to 1536 before division, so 24 more bytes will be added in both = cases. That is not one of the arguments I have made, but thanks for = pointing that out. >=20 > This is less than 2 bits more than actually required (on average), so = wastes less than 1/6200 of the bandwidth when full-sized packets = dominate the link (as is the usual case). Users are unlikely to notice = this in practice. Erm, VoIP packets are not close to full MTU so I am not sure = whether =E2=80=9Cas is the usual case=E2=80=9D is very convincing. = Actually your tendency to always =E2=80=9Cwing it=E2=80=9D instead of = doing research as shown when you claimed 64/65 bit encoding for PTM = instead of looking into the relevant standards (which I had to cite = twice to make you at least fix that misconception) does not not fill me = with confidence about those parts of cake where I do have zero = expertise. >=20 > Next to all the other stuff Cake does for each packet, the overhead = compensation is extremely quick. And, although the code looks very = similar, the PTM compensation is faster than the ATM compensation, = because the factor involved is a power of two (which GCC is very good at = optimising into shifts and masks). This is fortunate, since PTM is = typically used on higher-bandwidth links than ATM. I venture a guess that I have forgotten more about ATM/PTM = ADSL/VDSL than you ever bothered to read up on, so why do you keep = telling me these observations? If the goal is to annoy me, then mission = accomplished. >=20 > Now, if you can show me that the above is in fact incorrect - that = significant bandwidth is wasted on some real traffic profile, or that = cake_overhead() figures highly in a CPU profile on real hardware - then = I will reconsider. And that is great fun, the guy (you) that most often argues from = first principle instead of from real world data, requests actual data in = one of the cases where first principle seems quite applicable: when an = operation can be (almost) completely avoided. But I guess we just keep it as in the past; you keep not fully = grasping the intricacies of different XDSL/DOCSIS encodings and I keep = ridiculing you for the demonstrated lack of love to detail in these = matters.=20 In the past I sometimes wondered whether I did anything to = offend you by voicing my concerns in too brash or impolite way, but now = I simply assume that you (like most of us) simply do not react well to = criticism (even if justified) and prefer to just harass the messenger. >=20 > - Jonathan Morton >=20