From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D0C8321F21C for ; Fri, 24 Apr 2015 01:18:31 -0700 (PDT) Received: from u-089-d066.biologie.uni-tuebingen.de ([134.2.89.66]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MYx2x-1Yq7Nn3UKx-00VkGZ; Fri, 24 Apr 2015 10:18:20 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 24 Apr 2015 10:18:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C0D04CF-53AA-4D18-A4E4-B746AF6487C7@gmx.de> 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> To: jb X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:zWVnnQFaB7QN5Zqw9xbqyxu6WSvIszhb91McSZKHbpUtg1WVAuD aKIUBU1gcJLYtUsaR/cPMxCPVAVyAiFmIt8miaRQpmZYAVnCYDretIRKACFG7jtSVk5dA3i EViR9CL1mlXpTSxT1uGGyk0WSvp0ll0U+NhbThw/X7yWdHaVxgPDxwHN/fOnxhL35SAyRTu l5dP/IWwLncLxOlvf27EQ== X-UI-Out-Filterresults: notjunk:1; Cc: bloat 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: Fri, 24 Apr 2015 08:19:00 -0000 Hi jb, this looks great! On Apr 23, 2015, at 12:08 , jb wrote: > This is how I've changed the graph of latency under load per input = from you guys. >=20 > Taken away log axis. >=20 > 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. >=20 > Is it more descriptive? Mmmh, so the delay we see consists out of the delay caused by = the distance to the server and the delay of the access technology, = meaning the un-loaded latency can range from a few milliseconds to = several 100s of milliseconds (for the poor sods behind a satellite = link=85). Any further latency developing under load should be = independent of distance and access technology as those are already = factored in the bade latency. In both the extreme cases multiples of the = base-latency do not seem to be relevant measures of bloat, so I would = like to argue that the yellow and the red zones should be based on fixed = increments and not as a ratio of the base-latency. This is relevant as = people on a slow/high-access-latency link have a much smaller tolerance = for additional latency than people on a fast link if certain latency = guarantees need to be met, and thresholds as a function of base-latency = do not reflect this. Now ideally the colors should not be based on the base-latency = at all but should be at fixed total values, like 200 to 300 ms for voip = (according to ITU-T G.114 for voip one-way delay <=3D 150 ms is = recommended) in yellow, and say 400 to 600 ms in orange, 400ms is upper = bound for good voip and 600ms for decent voip (according to ITU-T = G.114,users are very satisfied up to 200 ms one way delay and satisfied = up to roughly 300ms) so anything above 600 in deep red? I know this is not perfect and the numbers will probably require = severe "bike-shedding=94 (and I am not sure that ITU-T G.114 really iOS = good source for the thresholds), but to get a discussion started here = are the numbers again: 0 to 100 ms no color 101 to 200 ms green 201 to 400 ms yellow 401 to 600 ms orange 601 to 1000 ms red 1001 to infinity purple (or better marina red?) Best Regards Sebastian >=20 > (sorry to the list moderator, gmail keeps sending under the wrong = email and I get a moderator message) >=20 > 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. >=20 > Taken away log axis. >=20 > 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. >=20 > Is it more descriptive? >=20 >=20 > 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. >=20 > Naive TCP pacing implementations were tried, and probably failed. >=20 > 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. >=20 > https://lwn.net/Articles/564978/ >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 >=20 > 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. >=20 > > 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 >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat