From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 A5E323B29F for ; Tue, 4 Oct 2016 07:19:04 -0400 (EDT) Received: by mail-lf0-x230.google.com with SMTP id t81so111949927lfe.0 for ; Tue, 04 Oct 2016 04:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jCVlFJQMflQ1NnZYioWWP1/IYTcNBN964Ur96yWgg1M=; b=W1Zw5xw+38/bW/VMbZwoHo8QN9h3ie9NvjRFzw7UTi44Q+86MwlbqbfQ7lorwtZ7+o KrzfpfLcdPQCwGSODJdtcZsT5uFR0Im78pD8q7OgbeXqaUVpwl3lvqnYBtPCKC7B1XIe bqU2jCFZzaPHCw/6aPN8wAX870W69niY96TWdn6lWFjWPhA4axzOjJZ9o+waNGxIslj8 Qv2ApSZF57S3qiZtsu1Lda+GvpiPvdtzsIcOumLxxisyrZ0Gis4NHiPu+nZdKgXYlrSm /YOakrFtPCLi93zzKFZfeJ7oMdfVi5hlpQMZkompRvxDbrxz2JVfzWSlIXL1i+upgLxN U3/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jCVlFJQMflQ1NnZYioWWP1/IYTcNBN964Ur96yWgg1M=; b=TlCoNWKRdYVKG9hKvxNJPk1Ci3fJE/mNGqWhKWWG+HCyGg9RvF76L0uwvX6//9x3/T 1s+A5jBnsc8xh00HVPy/rCftdY+U4vqumaLaiy9ogbLJB/EJPe8qsbHHUgYpUX85dIfG lzHVXqO0LIKq8t6SC2mogAVJbaAup85zsT0LAsHbafF4n7eQXrFotl6X98E0SMsY6g3G sSOllD4GsV1IzbsKVM8WUkxSkbT2KjymiQfWIJX+KOGs+rl4MemVmvmgR/Lqt0ciqCkl nekaSGeRvctjaW/uVv4cx1QZas4p5Dhw30IpRxoCycc3EsQBPuhZ5JdIsK30cjo1Un+C pdjw== X-Gm-Message-State: AA6/9RlbJLF7iIx56I7AOeEM57qRNpaRviCsN4p/sPwtkSr8g6s89tl4DOTRpKadbP4d5Q== X-Received: by 10.25.150.6 with SMTP id y6mr1034518lfd.160.1475579943386; Tue, 04 Oct 2016 04:19:03 -0700 (PDT) Received: from [192.168.100.13] (37-33-90-35.bb.dnainternet.fi. [37.33.90.35]) by smtp.gmail.com with ESMTPSA id r20sm621386lfr.19.2016.10.04.04.19.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Oct 2016 04:19:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <66438228-D13A-42C4-8B42-11C49E0B2587@gmx.de> Date: Tue, 4 Oct 2016 14:18:54 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <66438228-D13A-42C4-8B42-11C49E0B2587@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3124) 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:19:04 -0000 > 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? 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. 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. 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. I have been careful here to calculate ceil(len * 65/64) here, so that = the overhead is never underestimated. 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. 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. 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. 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. - Jonathan Morton