From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-03-iad.dyndns.com (mxout-122-iad.mailhop.org [216.146.32.122]) by lists.bufferbloat.net (Postfix) with ESMTP id 543CB2E0050 for ; Tue, 22 Feb 2011 14:24:01 -0800 (PST) Received: from scan-02-iad.mailhop.org (scan-02-iad.local [10.150.0.207]) by mail-03-iad.dyndns.com (Postfix) with ESMTP id D680E83470C for ; Tue, 22 Feb 2011 09:26:27 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 88.198.69.77 Received: from pax.zz.de (pax.zz.de [88.198.69.77]) by mail-03-iad.dyndns.com (Postfix) with ESMTP id 52A408345BA for ; Tue, 22 Feb 2011 09:26:26 +0000 (UTC) Received: by pax.zz.de (Postfix, from userid 1000) id 43F5662001; Tue, 22 Feb 2011 10:26:23 +0100 (CET) Date: Tue, 22 Feb 2011 10:26:23 +0100 From: Florian Lohoff To: Dan Siemon Message-ID: <20110222092623.GA11764@pax.zz.de> References: <1298330824.4443.17.camel@ganymede.coverfire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <1298330824.4443.17.camel@ganymede.coverfire.com> Organization: rfc822 - pure communication Sender: f@zz.de User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Network latency experiments 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: Tue, 22 Feb 2011 22:24:02 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 21, 2011 at 06:27:04PM -0500, Dan Siemon wrote: > I spent some time over the weekend playing around with different network > configurations and collecting latency results. Hopefully this is > interesting to the people on this list. >=20 > http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/ >=20 > Experiments > 1) Linux defaults > 2) Reduce buffers > 3) Reduce buffers + SFB > 4) Reduce buffers + SFQ >=20 > Each was tested under upstream load, downstream load and bidirectional > load. Hmmm - interesting - I am playing with tc and shaping on my upstream PPP for a while. The problem which i was fighting was that there is no real link =66rom the PPPoEs bandwidth to the real DSL Bandwidth as the underlying phy= sic is a 100MBit/s Ethernet so whatever your queue size is you push it out quit= e=20 fast and the queue building up at some point in the DSL modem which is=20 beyong the scope of tuning on the linux stack. So reducing the ethernet or ppp tx queue should not help anything here. I solved it with a "tc" htb with a 128kbit rate/ceil which is my upstream speed and a short queue (in the tc). One of the problems i see is missing backpressure due to completely unrelat= ed layer speeds. Id like to see DSL modems support something like ANCP to signal current up/downstream bandwidth towards the CPE - i could then add a rate limiter based on the current upstream bandwidth to=20 not overflow the DSL modem with upstream traffic, or in case of bufferbloat fixed DSL modems let the CPE choose packet scheduling not the dumb FIFO based DSL modem. Solving the DSL upstream buffer bload it possible with linux standard mechanisms - but its not "consumer friendly" or easy to use in some scenarios. "Open" DSL profiles are getting more and more common so your up and downstream bandwidth may change over time which makes it impossible to use fixed rate limiters. Solving this needs fixing the buffers in the intermediate devices like DSL and Cable Modems and some protocol to communi= cate the bandwidth to the IP layer for queue/scheduler configuration. Flo --=20 Florian Lohoff f@zz.de Professionell gesehen bin ich zu haben .... --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBTWOBP5DdQSDLCfIvAQg01A/6A2RamVUqDrRYSJPAVTY+SuqJf66awkIt ObiB/ZUE5mjBaP1zEy5OWmC48ms1RBTBVHRvGFGgsWNceHbuIGlqH2NQjEZWf/HY +DGZtGH7WpV3e+xnrcnBL0cjBbFxby9M2fHGMcpnaGy2tH4gSEyJYGNiDojC46/5 9nbbbzYp5oshvIjQRV+A+ee4HdijH9nFFUhfEVweyLHE5GmjdVSZKsYAkDW/6Gak HIN4g+pxWnTQ9f9aSb59uan+X7OfUw0VCy44UnywDC7PgZPda9dL4rwXKJYGB+xi JxSSMfmeMSFZOKhzbcCKDqlEh0qO8crlgIu0B5uuCuUIDO2JFII+5sVuZMlZMizz r7yav2jDFkgeXt1M7NCWXwg2oGwsz8wxegTvzBByBsvCkScXcAkreh1mssa68jn8 z4VfUbRYsZKk2AYjzemIcaZX7ZS67cMznsY0XcXsTGyxEXBDBFMIz9XutP3D1/y7 VVeVDSCBJci7drI4qEUT6X7QFs+vDKFlHMHOiDjGFkMi9S71uSb9vRTqDNCO2wF2 FGNzffR2YnYZX7m4Uc4t0/7XQ/wf4DyZRM6kRdzvw0Gm7Dq7RF5ZZCI0yeKbwlzf M5qjdUvABjWxFCKD19NPOsDH+t74IOuwOaJEOaj853fffGoIJ04XVHKJ1XJG8rkf t55vx0BrIHU= =s2kY -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--