From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 93CAF21F231 for ; Thu, 23 Apr 2015 03:08:33 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so19638054igb.0 for ; Thu, 23 Apr 2015 03:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=yQqXEvGhMpC0QjeHqJijivG9b6ZC9osxCsYMtGmMycc=; b=wUBDZRTW/wNGkcYR2JIpFhq9CZnWM6iU1XvazPcRjxwyNs8fDMMEnVHTr7liwsT9nX IXjl3aDWN6c+B0GQXAAszkr+2+v2vlYnOyAwUIVbfMC034PORDLCw49H5URynfpkswgg 4bjDRXM2dsoU/3reasveekCl6yG25pjQfkLXIkfPgT5dlBK9XI3pKxuUy7i0muu5Z1gd qnD0W0qf0VpxLQ02JQknG1wWqW8h82npBu49PXN+KrUmgM0bjYLf1p3Xq/2TArttPI+0 QuRToPRdvB7My2M5ToHKL/y1PVBwFkwqY9eSp77TsY6lqiD7gaIPWU4kEuWOuuDyB192 9a5g== MIME-Version: 1.0 X-Received: by 10.107.136.89 with SMTP id k86mr2489344iod.63.1429783712434; Thu, 23 Apr 2015 03:08:32 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Thu, 23 Apr 2015 03:08:32 -0700 (PDT) In-Reply-To: References: <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <20150422040453.GB36239@sesse.net> <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <553882D7.4020301@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> Date: Thu, 23 Apr 2015 20:08:32 +1000 X-Google-Sender-Auth: Iac9qEzNez6UtEUZXj29xjiL0Wc Message-ID: From: jb To: bloat Content-Type: multipart/alternative; boundary=001a1145a0724911c20514617645 Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in 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, 23 Apr 2015 10:09:01 -0000 --001a1145a0724911c20514617645 Content-Type: text/plain; charset=UTF-8 This is how I've changed the graph of latency under load per input from you guys. Taken away log axis. Put in two bands. Yellow starts at double the idle latency, and goes to 4x the idle latency red starts there, and goes to the top. No red shows if no bars reach into it. And no yellow band shows if no bars get into that zone. Is it more descriptive? (sorry to the list moderator, gmail keeps sending under the wrong email and I get a moderator message) On Thu, Apr 23, 2015 at 8:05 PM, jb wrote: > This is how I've changed the graph of latency under load per input from > you guys. > > Taken away log axis. > > Put in two bands. Yellow starts at double the idle latency, and goes to 4x > the idle latency > red starts there, and goes to the top. No red shows if no bars reach into > it. > And no yellow band shows if no bars get into that zone. > > Is it more descriptive? > > > On Thu, Apr 23, 2015 at 4:48 PM, Eric Dumazet > wrote: > >> Wait, this is a 15 years old experiment using Reno and a single test >> bed, using ns simulator. >> >> Naive TCP pacing implementations were tried, and probably failed. >> >> Pacing individual packet is quite bad, this is the first lesson one >> learns when implementing TCP pacing, especially if you try to drive a >> 40Gbps NIC. >> >> https://lwn.net/Articles/564978/ >> >> Also note we use usec based rtt samples, and nanosec high resolution >> timers in fq. I suspect the ns simulator experiment had sync issues >> because of using low resolution timers or simulation artifact, without >> any jitter source. >> >> Billions of flows are now 'paced', but keep in mind most packets are not >> paced. We do not pace in slow start, and we do not pace when tcp is ACK >> clocked. >> >> Only when someones sets SO_MAX_PACING_RATE below the TCP rate, we can >> eventually have all packets being paced, using TSO 'clusters' for TCP. >> >> >> >> On Thu, 2015-04-23 at 07:27 +0200, MUSCARIELLO Luca IMT/OLN wrote: >> > one reference with pdf publicly available. On the website there are >> > various papers >> > on this topic. Others might me more relevant but I did not check all of >> > them. >> >> > Understanding the Performance of TCP Pacing, >> > Amit Aggarwal, Stefan Savage, and Tom Anderson, >> > IEEE INFOCOM 2000 Tel-Aviv, Israel, March 2000, pages 1157-1165. >> > >> > http://www.cs.ucsd.edu/~savage/papers/Infocom2000pacing.pdf >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > --001a1145a0724911c20514617645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is how I've change= d the graph of latency under load per input from you guys.

Taken away log axis.

= Put in two bands. Yellow starts at double the idle latency, and goes to 4x = the idle latency
red starts there, and goes to the top. No red sh= ows if no bars reach into it.
And no yellow band shows if no bars= get into that zone.

Is it more descriptive?
=

(sorry to the list moderator, gmail keeps sending under= the wrong email and I get a moderator message)

On Thu, Apr 23, 2015 at 8:0= 5 PM, jb <justinbeech@gmail.com> wrote:
This is how I've changed the graph o= f latency under load per input from you guys.

Taken away log a= xis.

Put in two bands. Yellow starts at double the= idle latency, and goes to 4x the idle latency
red starts there, = and goes to the top. No red shows if no bars reach into it.
And n= o yellow band shows if no bars get into that zone.

Is it more descriptive?


On Thu, Apr 23, 2015 at 4:48 PM, Eric Dumazet <eric.dumazet@gmai= l.com> wrote:
Wait, this is= a 15 years old experiment using Reno and a single test
bed, using ns simulator.

Naive TCP pacing implementations were tried, and probably failed.

Pacing individual packet is quite bad, this is the first lesson one
learns when implementing TCP pacing, especially if you try to drive a
40Gbps NIC.

https://lwn.= net/Articles/564978/

Also note we use usec based rtt samples, and nanosec high resolution
timers in fq. I suspect the ns simulator experiment had sync issues
because of using low resolution timers or simulation artifact, without
any jitter source.

Billions of flows are now 'paced', but keep in mind most packets ar= e not
paced. We do not pace in slow start, and we do not pace when tcp is ACK
clocked.

Only when someones sets SO_MAX_PACING_RATE below the TCP rate, we can
eventually have all packets being paced, using TSO 'clusters' for T= CP.



On Thu, 2015-04-23 at 07:27 +0200, MUSCARIELLO Luca IMT/OLN wrote:
> one reference with pdf publicly available. On the website there are > various papers
> on this topic. Others might me more relevant but I did not check all o= f
> them.

> Understanding the Performance of TCP Pacing,
> Amit Aggarwal, Stefan Savage, and Tom Anderson,
> IEEE INFOCOM 2000 Tel-Aviv, Israel, March 2000, pages 1157-1165.
>
> http://www.cs.ucsd.edu/~savage/papers/Infocom2000pacing= .pdf


_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat


--001a1145a0724911c20514617645--