From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C8D7821F249 for ; Fri, 21 Mar 2014 08:39:18 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so691047wib.2 for ; Fri, 21 Mar 2014 08:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vBeRi4e0ZVp5YvcwZpcbHt0UetHnmGbWWk0RZ/0al8Y=; b=L60NkbdhKxqF8hTOHmgQLl7FMbZYr+aZsf+nO3ReUYJk6xIhPKk2qMigNmuV0lILz1 rSrHopBp0V+jw3Qkhypn4ufid5DEi04H0QEfmwNHb6XUJQTvaiQd/YtfWzI2o65RJLMZ nsVMAJbczOW08HsfGvC8zuClR4ALvBYSy+lR8MaWm0CNK3LFJcoBhI7EsInFhJy6Zx5t 3EHUTWrQd50EFciJUK+pKYhXsch2zDnbiPaOqhArJrKJa2JS1lx6K4Cfu7xvzgbab6Z9 MCHhhXgbAR0dUoxliwxXuW3dLyvw1Hob9OirYXOoCKXDOZ57FQ/3mJTu8PF53FX4RUwW iulA== MIME-Version: 1.0 X-Received: by 10.180.97.37 with SMTP id dx5mr2636320wib.53.1395416356491; Fri, 21 Mar 2014 08:39:16 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Fri, 21 Mar 2014 08:39:16 -0700 (PDT) In-Reply-To: <871txvbre7.fsf@toke.dk> References: <20140318145221.GA31327@sesse.net> <07BD4518-2A7E-4F43-8978-791E3B2BDA2A@cisco.com> <87eh1wc05c.fsf@toke.dk> <87a9ckbz1q.fsf@toke.dk> <871txvbre7.fsf@toke.dk> Date: Fri, 21 Mar 2014 15:39:16 +0000 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 15:39:19 -0000 On Fri, Mar 21, 2014 at 1:41 PM, Toke H=F8iland-J=F8rgensen = wrote: > 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. Oh, goodie. I was puzzled as to why the "fast" fq_codel queue was at 6ms instead of under 2ms, given the BQL size and traffic load. You'd think that data centers and distros would be falling over themselves to switch to sch_fq or sch_fq_codel to get 3x less latency than pfifo_fast = for sparse flows, at this point. It's just a sysctl away... > Updated the original graphs for the host-to-host. Retaining the pfifo_fast data is important as a baseline. Not a lot of point to graphing it further tho. I think you will find pie's behavior at these speeds bemusing. > 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) (question to list) Are there any options to tcpdump or the kernel to make it more possible to capture full packet payloads (64k) without loss at these speeds? tshark? (you might be able to get somewhere with port mirroring off the switch and a separate capture device.) /me sometimes likes living at 100Mbit and below > 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 --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html