From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 E4F1A21F405 for ; Fri, 24 Apr 2015 21:04:41 -0700 (PDT) Received: by oblw8 with SMTP id w8so51396126obl.0 for ; Fri, 24 Apr 2015 21:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XhKoaRZOMBcEGvfIw4kO2/Tj8Cgc2ByrmzsxAAf3+NU=; b=s2fKk0mN/v2MD/HB7pYBpoJH2CPYsIPidm+mezZx/f284T4qDETqolpIJn4qrnNP2A hnhU5cp8KOinlGpafkO191r4Tw9unsnTWk0cF7fB1f8HjcHhPCoGZgrXOmN4f5Evd4lD 1DX50VnogBzqpxNvXI+QMo+rRfXIuNaOf6xaR2Hod4FqAG6ALQaLDRvuhukqJ1i0P/M7 W52GCT4OynYKoas6wPwOySGtBChRh4sQ8KKPx60RPXca5nTfX5DjAR5F11I5HzKftGhO rxubP/oFyi9xdqMUqtZe+nKTbml1/E2BMyCVkQd3v+e2oWJJ0UqJvJ76+3yoWKA52qmP X7Ew== MIME-Version: 1.0 X-Received: by 10.182.29.101 with SMTP id j5mr1426842obh.0.1429934680628; Fri, 24 Apr 2015 21:04:40 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Fri, 24 Apr 2015 21:04:40 -0700 (PDT) In-Reply-To: <553B06CE.1050209@superduper.net> 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> Date: Fri, 24 Apr 2015 21:04:40 -0700 Message-ID: From: Dave Taht To: Simon Barber Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:05:10 -0000 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 conversati= on. > 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 o= f > 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=C3=B8iland-J=C3=B8rgensen wrote: >> >>> Sebastian Moeller writes: >>> >>>> I know this is not perfect and the numbers will probably require >>>> severe "bike-shedding=E2=80=9D >>> >>> Since you're literally asking for it... ;) >>> >>> >>> In this case we're talking about *added* latency. So the ambition shoul= d >>> 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 i= t >>> pretty close to this. Certainly under 20-30 ms of added latency. So fro= m >>> 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 limi= ts >> on externally relevant total latency thresholds would directly tell the = user >> which applications might run well on his link. Sure this means that peop= le >> on a satellite link most likely will miss out the acceptable voip thresh= old >> by their base-latency alone, but guess what telephony via satellite leav= es >> 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 und= er >> load, given that during load both base and induced latency come into pla= y. 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 li= kes >> to think of remote desktop as an oil tanker simulator ;) ) >> >>> The other increments I have less opinions about, but 100 ms does seem t= o >>> be a nice round number, so do yellow from 30-100 ms, then start with th= e >>> 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 --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67