From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6E54221F41D for ; Fri, 24 Apr 2015 21:26:55 -0700 (PDT) Received: from 199-116-72-167.public.monkeybrains.net ([199.116.72.167] helo=[192.168.0.12]) by masada.superduper.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128) (Exim 4.80) (envelope-from ) id 1Ylrg0-0002z4-81; Sat, 25 Apr 2015 05:26:52 +0100 From: Simon Barber To: Dave Taht Date: Fri, 24 Apr 2015 21:26:44 -0700 Message-ID: <14ceed3c818.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> In-Reply-To: References: <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> <6C0D04CF-53AA-4D18-A4E4-B746AF6487C7@gmx.de> <87wq123p5r.fsf@toke.dk> <2288B614-B415-4017-A842-76E8F5DFDE4C@gmx.de> <553B06CE.1050209@superduper.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.0.19 (build: 2100846) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) 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: Sat, 25 Apr 2015 04:27:24 -0000 Certainly the VoIP numbers are for peak total latency, and while Justin is measuring total latency because he is only taking a few samples the peak values will be a little higher. Simon Sent with AquaMail for Android http://www.aqua-mail.com On April 24, 2015 9:04:45 PM Dave Taht wrote: > simon all your numbers are too large by at least a factor of 2. I > think also you are thinking about total latency, rather than induced > latency and jitter. > > Please see my earlier email laying out the bands. And gettys' manifesto. > > If you are thinking in terms of voip, less than 30ms *jitter* is what > you want, and a latency increase of 30ms is a proxy for also holding > jitter that low. > > > On Fri, Apr 24, 2015 at 8:15 PM, Simon Barber wrote: > > I think it might be useful to have a 'latency guide' for users. It would say > > things like > > > > 100ms - VoIP applications work well > > 250ms - VoIP applications - conversation is not as natural as it could be, > > although users may not notice this. > > 500ms - VoIP applications begin to have awkward pauses in conversation. > > 1000ms - VoIP applications have significant annoying pauses in conversation. > > 2000ms - VoIP unusable for most interactive conversations. > > > > 0-50ms - web pages load snappily > > 250ms - web pages can often take an extra second to appear, even on the > > highest bandwidth links > > 1000ms - web pages load significantly slower than they should, taking > > several extra seconds to appear, even on the highest bandwidth links > > 2000ms+ - web browsing is heavily slowed, with many seconds or even 10s of > > seconds of delays for pages to load, even on the highest bandwidth links. > > > > Gaming.... some kind of guide here.... > > > > Simon > > > > > > > > > > On 4/24/2015 1:55 AM, Sebastian Moeller wrote: > >> > >> Hi Toke, > >> > >> On Apr 24, 2015, at 10:29 , Toke Høiland-Jørgensen wrote: > >> > >>> Sebastian Moeller writes: > >>> > >>>> I know this is not perfect and the numbers will probably require > >>>> severe "bike-shedding” > >>> > >>> Since you're literally asking for it... ;) > >>> > >>> > >>> In this case we're talking about *added* latency. So the ambition should > >>> be zero, or so close to it as to be indiscernible. Furthermore, we know > >>> that proper application of a good queue management algorithm can keep it > >>> pretty close to this. Certainly under 20-30 ms of added latency. So from > >>> this, IMO the 'green' or 'excellent' score should be from zero to 30 ms. > >> > >> Oh, I can get behind that easily, I just thought basing the limits > >> on externally relevant total latency thresholds would directly tell the user > >> which applications might run well on his link. Sure this means that people > >> on a satellite link most likely will miss out the acceptable voip threshold > >> by their base-latency alone, but guess what telephony via satellite leaves > >> something to be desired. That said if the alternative is no telephony I > >> would take 1 second one-way delay any day ;). > >> What I liked about fixed thresholds is that the test would give a > >> good indication what kind of uses are going to work well on the link under > >> load, given that during load both base and induced latency come into play. I > >> agree that 300ms as first threshold is rather unambiguous though (and I am > >> certain that remote X11 will require a massively lower RTT unless one likes > >> to think of remote desktop as an oil tanker simulator ;) ) > >> > >>> The other increments I have less opinions about, but 100 ms does seem to > >>> be a nice round number, so do yellow from 30-100 ms, then start with the > >>> reds somewhere above that, and range up into the deep red / purple / > >>> black with skulls and fiery death as we go nearer and above one second? > >>> > >>> > >>> I very much think that raising peoples expectations and being quite > >>> ambitious about what to expect is an important part of this. Of course > >>> the base latency is going to vary, but the added latency shouldn't. And > >>> sine we have the technology to make sure it doesn't, calling out bad > >>> results when we see them is reasonable! > >> > >> Okay so this would turn into: > >> > >> base latency to base latency + 30 ms: green > >> base latency + 31 ms to base latency + 100 ms: yellow > >> base latency + 101 ms to base latency + 200 ms: orange? > >> base latency + 201 ms to base latency + 500 ms: red > >> base latency + 501 ms to base latency + 1000 ms: fire > >> base latency + 1001 ms to infinity: > >> fire & brimstone > >> > >> correct? > >> > >> > >>> -Toke > >> > >> _______________________________________________ > >> Bloat mailing list > >> Bloat@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > > > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > > > -- > Dave Täht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67