From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (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 B97C6201A42 for ; Fri, 13 May 2011 07:46:11 -0700 (PDT) Received: by iwn8 with SMTP id 8so3536343iwn.16 for ; Fri, 13 May 2011 07:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oP08h5ASZHwJ6ZDrfh3HYU/gxPoivIGacqaXuTH0kZs=; b=OQFNX4XRISd/zmAPlSM9loPWL8pOedUaTNEQHmn9Iay/iCV55vo4a+k9wI4yijNLll q+H0RXgTYF6XJGlNsO0VG1jaPdRajZdAE8d0F7YA4kCH5GKryoqoNXuNJ7NZxbhURHOf L5ygiJIN0r29NdBBNfdx5HBZ6SqE/J7cw9Pik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jnrzlh/FBmVBq/g3eEB0L/u5r6gzh14MjXzO31ovZhTRpnT+FCeCzZTzRyHoxO9tV6 DIRegIH6gbzn5JUJqWRIiejKbOA9u7ByPunYJ8Znf4BV9/igfdv9Cvnbexj0u49wkNpV WPW2Da4ZiNo8d3y7B/2bqsQg0RvVFtdjrdXAc= MIME-Version: 1.0 Received: by 10.231.215.3 with SMTP id hc3mr1187161ibb.156.1305298467059; Fri, 13 May 2011 07:54:27 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Fri, 13 May 2011 07:54:26 -0700 (PDT) In-Reply-To: <1305297321.8149.549.camel@tardy> References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <20110505091046.3c73e067@nehalam> <6E25D2CF-D0F0-4C41-BABC-4AB0C00862A6@pnsol.com> <35D8AC71C7BF46E29CC3118AACD97FA6@srichardlxp2> <1304964368.8149.202.camel@tardy> <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> <1305297321.8149.549.camel@tardy> Date: Fri, 13 May 2011 08:54:26 -0600 Message-ID: From: Dave Taht To: rick.jones2@hp.com Content-Type: multipart/alternative; boundary=000e0cd4d4dc747b1704a3297b58 Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Burst Loss 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, 13 May 2011 14:46:12 -0000 --000e0cd4d4dc747b1704a3297b58 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2011 at 8:35 AM, Rick Jones wrote: > On Thu, 2011-05-12 at 23:00 -0600, Kevin Gross wrote: > > One of the principal reasons jumbo frames have not been standardized > > is due to latency concerns. I assume this group can appreciate the > > IEEE holding ground on this. > > Thusfar at least, bloaters are fighting to eliminate 10s of milliseconds > of queuing delay. I don't think this list is worrying about the tens of > microseconds difference between the transmission time of a 9000 byte > frame at 1 GbE vs a 1500 byte frame, or the single digit microseconds > difference at 10 GbE. > Heh. With the first iteration of the bismark project I'm trying to get to where I have less than 30ms latency under load and have far larger problems to worry about than jumbo frames. I'll be lucky to manage 1/10th that (300ms) at this point. Not, incidentally that I mind the idea of jumbo frames. It seems silly to b= e saddled with default frame sizes that made sense in the 70s, and in an age where we will be seeing ever more packet encapsulation, reducing the header size as a ratio to data size strikes me as a very worthy goal. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --000e0cd4d4dc747b1704a3297b58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2011 at 8:35 AM, Rick Jo= nes <rick.jones2= @hp.com> wrote:
On Thu, 2011-05-12 at 23:00 -0600, Kevin Gross wrote:
> One of the principal reasons jumbo frames have not been standardized > is due to latency concerns. I assume this group can appreciate the
> IEEE holding ground on this.

Thusfar at least, bloaters are fighting to eliminate 10s of milliseco= nds
of queuing delay. =A0I don't think this list is worrying about the tens= of
microseconds difference between the transmission time of a 9000 byte
frame at 1 GbE vs a 1500 byte frame, or the single digit microseconds
difference at 10 GbE.

Heh.=A0 With the first itera= tion of the bismark project I'm trying to get to where I have less than= 30ms latency under load and have far larger problems to worry about than j= umbo frames. I'll be lucky to manage 1/10th that (300ms) at this point.=

Not, incidentally that I mind the idea of jumbo frames. It seems silly = to be saddled with default frame sizes that made sense in the 70s, and in a= n age where we will be seeing ever more packet encapsulation, reducing the = header size as a ratio to data size strikes me as a very worthy goal.



--
Dave T=E4ht
SKYPE: davetaht=
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--000e0cd4d4dc747b1704a3297b58--