From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) (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 A839721F242 for ; Fri, 21 Mar 2014 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-kau.localdomain (Postfix, from userid 1000) id 943178FB7B; Fri, 21 Mar 2014 14:41:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1395409300; bh=o1YIx4piaUO5NQW3CzzbZ3tiGJ7wm7477voamzvCHw0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=iyptZr6rhHl7b7Tv7tn+JPZL/it8DPIFV8IxfkRu6MMTOwM+DD+5EQBaRBa5qCnls ihOtOS+lebzwAqBlWedwHMP1olcZkfW47XWmRZjHGZ401Q99w16DNLGCASP9e+x3pR gIqGUpxVsU9TBDz8cJpxTeL+AHKz7NF4tA2T1syM= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht References: <20140318145221.GA31327@sesse.net> <07BD4518-2A7E-4F43-8978-791E3B2BDA2A@cisco.com> <87eh1wc05c.fsf@toke.dk> <87a9ckbz1q.fsf@toke.dk> Date: Fri, 21 Mar 2014 14:41:36 +0100 In-Reply-To: (Dave Taht's message of "Thu, 20 Mar 2014 10:14:35 -0700") Message-ID: <871txvbre7.fsf@toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: bloat Subject: Re: [Bloat] AQM creeping into L2 equipment 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: Fri, 21 Mar 2014 13:41:50 -0000 --=-=-= Content-Type: text/plain Dave Taht writes: > I imagine with the new tcp's pfifo_fast is going to be sub 8ms also. Yeah, turns out I botched the qdisc setup (put it on the wrong interface on one of the servers) for the case with no switch. So the ~6ms was with pfifo_fast in one end. Updated the original graphs for the host-to-host. Data capture files are here: http://kau.toke.dk/experiments/cisco-switch/packet-captures/ -- no idea why the client seems to capture three times as many packets as the server. None of them seem to think they've dropped any (as per tcpdump output). Will add dumps from going through the switch in a bit... > Is your hardware fast enough to run tcpdump -s 128 -w whatever.cap -i > your interface during an entire rrul test without dropping packets? > (on client and server) Well, as above, tcpdump doesn't say anything about dropped packets; but since the client dump is way bigger, perhaps the server-side does anyway? -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTLEGQAAoJEENeEGz1+utPUs8IALDxBkL7iW+KNrUDQl7E3tOp iAD6wHPVTq1647ITGoWvtqwnUTTVOKV4hl9/SiAerPyyXaiYIvnwpsyo23xKG4oA A9VxjuHKeXlRzwiBjLfSu7eto5D/AaV15tlc6tBgtUoiChTjzjZi3mgtJzP8lbYD T6iQ53wGnTDdtgKocrw9kqrY2BPsKndBUwAx89GvoqSO7KBfn9v1lyippCcDkJys 9B0pvUegIVL/7lLWowJPszXpVqtFj0xs48gDhi3mSmsW/yyg5H8dDWJDihO2l5a7 RAwr6D4vJ9BE5a2Orc/BtnXBH/xaThQTtS2TqSkVEMB+6q76h8D2elKTFSOaMaA= =MEAy -----END PGP SIGNATURE----- --=-=-=--