From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alpha.coverfire.com (dsiemon-2-pt.tunnel.tserv21.tor1.ipv6.he.net [IPv6:2001:470:1c:44e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7927021F176; Wed, 5 Dec 2012 20:12:53 -0800 (PST) Received: from [192.168.88.98] (titan.home [69.41.199.68]) (authenticated bits=0) by alpha.coverfire.com (8.14.5/8.14.5) with ESMTP id qB64CotO025941 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 23:12:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coverfire.com; s=alpha2011102501; t=1354767170; bh=ZWtW+2fU5iZf+OUB/MBXHSKbd3Br6k40eJXZL4MYago=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=U9sqSJel41KQX3jVU/3P0CrC1tFXHOOTHFJ9syUrmVPtuQfsxYo1ePI2p3I/dysUn bNJ833YlfELknuDWvgc/CmtzPBwS7DILqBjGMYgRzeJQUVzrgeBGU+9Xn7Y8b9jXAL VTg/jWbd0rc4VMqPN+OOAVFqhrQ4FDmUko3M5og4= Message-ID: <1354767169.29387.21.camel@ganymede.home> From: Dan Siemon To: Alex Burr Date: Wed, 05 Dec 2012 23:12:49 -0500 In-Reply-To: <1354739624.4431.YahooMailNeo@web126205.mail.ne1.yahoo.com> References: <20121123221842.GD2829@linux.vnet.ibm.com> <20121128172058.GB2474@linux.vnet.ibm.com> <20121202230635.GA16359@linux.vnet.ibm.com> <87obib5qf8.fsf@toke.dk> <1354550303.24281.103.camel@shinybook.infradead.org> <1354590837.29387.9.camel@ganymede.home> <1354613026.72238.YahooMailNeo@web126202.mail.ne1.yahoo.com> <1354678874.29387.12.camel@ganymede.home> <1354739624.4431.YahooMailNeo@web126205.mail.ne1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-42DpJYckCg4WBN3J2bGK" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.73 on 69.41.199.58 X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on alpha.coverfire.com Cc: "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] [Codel] [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 04:12:53 -0000 --=-42DpJYckCg4WBN3J2bGK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-12-05 at 12:33 -0800, Alex Burr wrote: > > From: Dan Siemon >=20 >=20 > > Thanks for the info. I guess I'll have to keep digging to figure out > > where the latency comes from. > >=20 > > I did a couple more experiments which appear to confirm the large amoun= t > > of per-packet overhead: > > http://www.coverfire.com/archives/2012/12/04/per-packet-overhead-on-vds= l2-2/ > > >=20 > It almost looks like you're being limited to 5k packets/sec. Now, I > know that some devices will only support a certain packet rate, and > it's not as stupid as it sounds because it's fairly rare to want to > send max rate of solely minimum size packets. But I wouldn't expect it > here, because I would expect a VDSL2 device to work with 100Mbps down, > 50Mbps up, even if your contract and line only support much less. And > the device would need to support more than 5k packets/sec to get > 50Mbps, even at the biggest packet size. I guess you might be able to > tell by plotting packet rate against packet size with more values of > packet size: if it's a rate limit, there will be a sharp corner, > whereas if it's overhead, there will should be more of a curve. The > figure for the 75byte payload suggests a curve. I ran the same test with more small packet sizes: http://www.coverfire.com/archives/2012/12/05/per-packet-overhead-on-vdsl-3/ This looks like it supports the PPS limit theory.=20 > PTM-TC has a minimum overhead of 2 bytes/packet, IIRC. (I'm not > counting the 65/64 cell overhead, because that is not (in a good > implementation) aligned to packet boundaries and is therefore better > thought of as a 1/65 tax on your line rate). I'm not optimistic about > tuning shapers based on these details, however, as unlike ATM/AAL5, > implementations are allowed to insert any amount of padding between > packets, so the per packet overhead is not predictable from the > standard. There are also nonstandard framing implementations.=20 That's disappointing news. My VDSL2 modem (Alcatel Cellpipe 7130) shows: Upstream line rate: 7344 kbps Bearer Upstream payload rate: 6560 kbps Can you shed some light on what causes the difference? Is it the 65/64 encoding and error correction overhead? I assume this does not take into account things like the 802.3 header. Thanks --=-42DpJYckCg4WBN3J2bGK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABCAAGBQJQwBtBAAoJEJKXGLoTP2w+xc4QAJkcE9vWU55aKntQVC7OkBa9 Gsm483c/TVKTFbS+49DiGjVuDv1lX76i6UNL9eFV7AmC34JnLMA2zeZOG0VhBWgX Qz9jjH2hvMQ2Jab5vNDxG+6YOOGmbAtRIKj3m2zBHtEXEOqTXS5me/uTAlR8sKCu 490MAOzCJjm3sk9aTeXpKjFYREVAlAQEL8Bt8ldClF7zUjxa58KxbJsiYW3kojzt eCsn+l3t5WdQ0T+HD+JXnfQP4EjgqIWnaOmHT7Q8jCnRWzoo1sYHFtGE7kRRFZKe A9WLHcoFfyO0qUU0Rz2nKtSWQxfo8CT+NvCoJ6c2iyKe//Q0lExnD9ShbPSPp7yu 7FGMibDyKnKHMzsMKvn4PYnJBjNBhaavVsAlak3/ylWvIyg3LEtQzojpoua5YLfL L9/4A+L8VIh/kCN2NvnFuXdv1pNcQlVee8qq9zhHuqrNaAAVraj3N6jhyTGQolf3 RgPZH/9geTzDa5jFRYmeYW2T6pJyOMdH4Zx9nNR6WmQk1ONjnHLu33CtJmbKBLdm 6S38/AmzQ5Dt0wj/HJ67EdKxjGhVIOYdfb5ELGBD8kFrvQEj4GK4xnuMqrorYEYR Zr0QsBX9b/qOmfQUfcgMdtK0r1NCjxf9L67yr6/4Wl4ObAxiHNdoECBF6ardmKU2 E8noS/QJ8QE4agZ8I4sc =lljs -----END PGP SIGNATURE----- --=-42DpJYckCg4WBN3J2bGK--