From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CB8DD21F0AE for ; Thu, 28 Mar 2013 16:05:20 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id a11so55479iee.39 for ; Thu, 28 Mar 2013 16:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=p/OFputIRfdRj9dtghhswmWnJ9b5HfA7vNmzoaMMuT8=; b=lwZxmTX0CTn+H+USmKCEM8kV3bVNpgkiSrkwfosvDO45JEXvqPHshmzjXoz/Dv3/9R p3mYIyLDQ15aQn6lFYZRDsydpVchXa/1ur9FKUILlgicRZSYGVoesDDAIa27gATXpX5m AOgvGOv2hXNg+BqAJ4EIAcY55gAMPtZEBSHT/1y8gBX/pgebuupUQvqC4bD907lWWcg1 NkjX+9zwpr7c5eeKMwYGUj0eoUQMpPAJJFuwQsHDMqVU2ohR24hsNpewm00MMPig6R38 ReQxfsDnje/Pp3dOn8LLEPrkRguHmojmk543/Zq53lC8XF5UDwBlYinSM/UwoQtv48Ix oDpA== MIME-Version: 1.0 X-Received: by 10.50.134.4 with SMTP id pg4mr236985igb.96.1364511919734; Thu, 28 Mar 2013 16:05:19 -0700 (PDT) Received: by 10.64.132.71 with HTTP; Thu, 28 Mar 2013 16:05:19 -0700 (PDT) Date: Thu, 28 Mar 2013 16:05:19 -0700 Message-ID: From: Dave Taht To: bloat Content-Type: multipart/alternative; boundary=047d7b3a98b844878404d90430de Cc: =?ISO-8859-1?Q?H=E5vard_Staub_Nyhus?= , Marius Hole Subject: [Bloat] latency looks good again at the gathering 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, 28 Mar 2013 23:05:21 -0000 --047d7b3a98b844878404d90430de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bloat list: I note that yesterday's problem with the long period latency swings was narrowed down to a bad card or connector in the chassis, and that fiber connection has been disabled. I've got packet captures covering a goodly percentage of the universe now (thanks to the hard work of the cc'd).... and occasionally I do things like checking ipv6 vs ipv4 performance going internationally so as to have a reference later. http://gathering-edge.bufferbloat.net/~d/california/california_46compete-3.= svg Interesting about the ping part of the plot - there seems to be some classification on the link, and it's neat that BE traffic stops (packet loss there), that the EF traffic has got a different RTT than the BK (CS1) traffic (which is the lowest latency of the bunch!!!) , and that ipv6 has lower latency than ipv4 on this path(s). (duh= ) as for the periodic bits of long period TCP changes, darned if I know... that's what I have packet captures for. you can see some sort of major packet loss event at T+168 or so here: http://gathering-edge.bufferbloat.net/~d/california/california_46compete-lo= ng-3.svg As to where it occurred, well, darn it, "mtr" was part of the rrul spec and haven't got around to integrating it. Anyway, another long period 6vs4 http://gathering-edge.bufferbloat.net/~d/california/california_46compete-lo= ng-600.svg --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --047d7b3a98b844878404d90430de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bloat list:

I note that yesterday's problem with the long period= latency swings was narrowed down to a bad card or connector in the chassis= , and that fiber connection has been disabled.

I've got packet c= aptures covering a goodly percentage of the universe now (thanks to the har= d work of the cc'd).... and occasionally I do things like checking ipv6= vs ipv4 performance going internationally so as to have a reference later.=

http://gathering-edge.bufferbloat.net= /~d/california/california_46compete-3.svg

Interesting about the = ping part of the plot - there seems to be some classification on the link, = and it's neat
that BE traffic stops (packet loss there), that the EF traffic has got a di= fferent RTT than the BK (CS1) traffic (which is the lowest latency of the b= unch!!!) , and that ipv6 has lower latency than ipv4 on this path(s). (duh)=

as for the periodic bits of long period TCP changes, darned if I know..= . that's what I have packet captures for.

you can = see some sort of major packet loss event at T+168 or so here:

http://gathering-edge.bufferbloat.net/~d/california/californ= ia_46compete-long-3.svg

As to where it occurred, well, darn it,=A0 "mtr" was part of = the rrul spec and haven't got around to integrating it.

Anyway, = another long period 6vs4

http://gathering-edg= e.bufferbloat.net/~d/california/california_46compete-long-600.svg


--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http:= //www.teklibre.com/cerowrt/subscribe.html=20 --047d7b3a98b844878404d90430de--