From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1CD553B29F for ; Tue, 4 Oct 2016 12:23:42 -0400 (EDT) Received: by mail-pf0-x22a.google.com with SMTP id 190so30495068pfv.0 for ; Tue, 04 Oct 2016 09:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5IKjTixajH9LYL7JULv0rMzdBUvM616wSCxxIY/VpxA=; b=uvijkCfHBXgiYCDDmEZikuSKbtsAT4gYwXDD7DbFkPUENo+QYLmlSoQwYONXLskGHx /uIy19Vqi6gUY3Okjs+RvboH5uThae3ypKPifKTeNBa2K7ntiG/Mpy4HdEZOVU4D1ozK SiG2jIgG7oavpvABZzpNOvycbnMGQHP6IigJo/pzQ9H6snjptsP/GjtA6u0XkMj2pu0M a3Xlbv45ztsWpk12MCNsNxV7WyMXZ1fYEJQu9j140qJX8K024omJj92D4HqdH/hq5jYs 4TCffOrpvvg8eZ+61ciy8Bo9p8B4+8RTiyWRSvB3sSODTj05E1BscgvYzitk3o0y/Ozj Pn6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5IKjTixajH9LYL7JULv0rMzdBUvM616wSCxxIY/VpxA=; b=kTtdhYRogQj0ZJBtO1X4ehjMx0OCD1yRny3HYQurRugxbA2+hZ7ez4NcAYdmqO7y3l iAj6VEf9x+UJtOc+gcg/shY0wDXCExA2AbueSulv4mSH8gb7Jlxz6iU/8rH6oOrq80Co s1gq5MtdEQphlNV9tMOT+LIe432qapvSxH6MmMjyMuw4b/klI0zff0ysk1Wf5CJJzKcO YXtMPsyVkSXtMFwRHlqiAKRIccvGyie6VpD1Psdeo2ZN41DBovq/tDYlF2YQLdGLOM1P T5kirUPTMUqdtoaIOCPIaCpFWnGoYz5Eu8GdBQO0xpEjSfbTCp6sxngokCATKdp7JCJz 2LzA== X-Gm-Message-State: AA6/9RneaBBuu3yfQ2qFImg39o3+wfaawrDijsQyZt4Dw9IKftJxmjAQ10OWHHTerrQ+4ZzS+YEc4oEMPjrpbg== X-Received: by 10.98.87.90 with SMTP id l87mr7268697pfb.121.1475598221208; Tue, 04 Oct 2016 09:23:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.102.70 with HTTP; Tue, 4 Oct 2016 09:23:40 -0700 (PDT) In-Reply-To: <0B21E94A-EEF5-44A4-A6C8-1653BC983246@gmx.de> References: <66438228-D13A-42C4-8B42-11C49E0B2587@gmx.de> <0B21E94A-EEF5-44A4-A6C8-1653BC983246@gmx.de> From: Loganaden Velvindron Date: Tue, 4 Oct 2016 20:23:40 +0400 Message-ID: To: moeller0 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 16:23:42 -0000 On Tue, Oct 4, 2016 at 3:54 PM, moeller0 wrote: > Hi Jonathan, > >> On Oct 4, 2016, at 13:18 , Jonathan Morton wrote= : >> >> >>> On 4 Oct, 2016, at 11:46, moeller0 wrote: >>> >>> About that PTM accounting, could you explain why you want to perform th= e adjustment as a a =E2=80=9Cvirtual=E2=80=9D size increase per packet inst= ead of a =E2=80=9Cvirtual=E2=80=9D rate reduction? >> >> 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 pac= kets. >> >> 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 s= econd. 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 b= etter modeled as a rate reduction than as a size increase, even though in e= ssence for a shaper you can account for it either way. > >> >> I=E2=80=99m quite keen to keep the =E2=80=9Cbytes per second=E2=80=9D pu= rely derived from the raw bitrate of the link, because that is the value wi= dely advertised by ISPs and network equipment manufacturers everywhere. He= nce, overhead compensation is implemented purely by increasing the accounte= d size of the packets. > > Sorry that does not make much sense, I realize that mathematicall= y 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 oth= er real option (unless you work with a fixed packet length), but generic ra= te reductions do not need to be recomputed for each packet. > > >> >> I have been careful here to calculate ceil(len * 65/64) here, so that th= e 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. A= s 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 152= 7 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 poin= ting that out. > >> >> This is less than 2 bits more than actually required (on average), so wa= stes 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 practic= e. > > Erm, VoIP packets are not close to full MTU so I am not sure whet= her =E2=80=9Cas is the usual case=E2=80=9D is very convincing. Actually you= r 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. > >> >> Next to all the other stuff Cake does for each packet, the overhead comp= ensation is extremely quick. And, although the code looks very similar, th= e 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 shift= s and masks). This is fortunate, since PTM is typically used on higher-ban= dwidth links than ATM. > > I venture a guess that I have forgotten more about ATM/PTM ADSL/V= DSL than you ever bothered to read up on, so why do you keep telling me the= se observations? If the goal is to annoy me, then mission accomplished. > >> >> Now, if you can show me that the above is in fact incorrect - that signi= ficant bandwidth is wasted on some real traffic profile, or that cake_overh= ead() figures highly in a CPU profile on real hardware - then I will recons= ider. > > 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 on= e of the cases where first principle seems quite applicable: when an operat= ion can be (almost) completely avoided. > > But I guess we just keep it as in the past; you keep not fully gr= asping the intricacies of different XDSL/DOCSIS encodings and I keep ridicu= ling you for the demonstrated lack of love to detail in these matters. > 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 (ev= en if justified) and prefer to just harass the messenger. > >> >> - Jonathan Morton >> > Perhaps a good way to move forward on this might be to have some kind of hackathon, and have a face to face discussion so that we could move on ? > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake