From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 5BED521F24D for ; Mon, 27 Apr 2015 09:41:09 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so87590577obb.3 for ; Mon, 27 Apr 2015 09:39:10 -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=wfIIxVxVaveM/nQYpjBuMhgbvVLB5VV3MvXFa8wF2lg=; b=jiEKxJ/NemaT5LEOYMFSBI1Tt8VmCy3lNJ4rdQcmD2MWJeZlAK/yAGhwkCyQquWhx5 r4ZxxsDRPPvQr6ZI9cpY8XtH8oFkfpEHdgwzMKXMUbni05IACZOoDyiq9uhg7UEbJz58 kxDh/PmdEmMjv5yskb+b1QYZXP4gNUNF0BY2YJs6mEETxSv76ABVb0riPVbRZNa3tPxo uoTQO3OT+6ZNvQ6HcAW0jziwT+mNs2LUCOpdQnE1AgRKi/kaC59fckWIO9GXbVXNayI3 WlCpxY6FD5sKe6yqjw2rnV2sX+rF5yGomzoym5kyQydWxNpfhQN+s6gORX2aVA0cRPFJ iU4w== MIME-Version: 1.0 X-Received: by 10.60.60.70 with SMTP id f6mr10698138oer.8.1430152749696; Mon, 27 Apr 2015 09:39:09 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Mon, 27 Apr 2015 09:39:09 -0700 (PDT) In-Reply-To: <0C930D43-A05B-48E2-BC01-792CAA72CAD1@gmx.de> 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> <14ceed3c818.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <0C930D43-A05B-48E2-BC01-792CAA72CAD1@gmx.de> Date: Mon, 27 Apr 2015 09:39:09 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller 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: Mon, 27 Apr 2015 16:43:29 -0000 On Fri, Apr 24, 2015 at 11:03 PM, Sebastian Moeller wrote= : > Hi Simon, hi List > > On Apr 25, 2015, at 06:26 , Simon Barber wrote: > >> 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. > > If your voip number are for peak total latency they need literatu= re citations to back them up, as they are way shorter than what the ITU rec= ommends for one-way-latency (see ITU-T G.114, Fig. 1). I am not "married=E2= =80=9D to the ITU numbers but I think we should use generally accepted numb= ers here and not bake our own thresholds (and for all I know your numbers a= re fine, I just don=E2=80=99t know where they are coming from ;) ) At one level I am utterly prepared to set new (And lower) standards for latency, and not necessarily pay attention to compromise driven standards processes established in the 70s and 80s, but to the actual user experience numbers that jim cited in the fq+aqm manefesto on his blog. I consider induced latencies of 30ms as a "green" band because that is the outer limit of the range modern aqm technologies can achieve (fq can get closer to 0). There was a lot of debate about 20ms being the right figure for induced latency and/or jitter, a year or two back, and we settled on 30ms for both, so that number is already a compromise figure. It is highly likely that folk here are not aware of the extra-ordinary amount of debate that went into deciding the ultimate ATM cell size back in the day. The eu wanted 32 bytes, the US 48, both because that was basically a good size for the local continental distance and echo cancellation stuff, at the time. In the case of voip, jitter is actually more important than latency. Modern codecs and coding techniques can tolerate 30ms of jitter, just barely, without sound artifacts. >60ms, boom, crackle, hiss. > Best Regards > Sebastian > > >> >> 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 wr= ote: >>> > I think it might be useful to have a 'latency guide' for users. It wo= uld say >>> > things like >>> > >>> > 100ms - VoIP applications work well >>> > 250ms - VoIP applications - conversation is not as natural as it coul= d be, >>> > although users may not notice this. > > The only way to detect whether a conversation is natural is if us= ers notice, I would say... > >>> > 500ms - VoIP applications begin to have awkward pauses in conversatio= n. >>> > 1000ms - VoIP applications have significant annoying pauses in conver= sation. >>> > 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 t= he >>> > 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 1= 0s of >>> > seconds of delays for pages to load, even on the highest bandwidth li= nks. >>> > >>> > 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 s= hould >>> >>> be zero, or so close to it as to be indiscernible. Furthermore, we = know >>> >>> that proper application of a good queue management algorithm can ke= ep 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 3= 0 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 th= reshold >>> >> by their base-latency alone, but guess what telephony via satellite = leaves >>> >> something to be desired. That said if the alternative is no telephon= y I >>> >> would take 1 second one-way delay any day ;). >>> >> What I liked about fixed thresholds is that the test would g= ive 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 (an= d I am >>> >> certain that remote X11 will require a massively lower RTT unless on= e likes >>> >> to think of remote desktop as an oil tanker simulator ;) ) >>> >> >>> >>> The other increments I have less opinions about, but 100 ms does se= em to >>> >>> be a nice round number, so do yellow from 30-100 ms, then start wit= h 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 sec= ond? >>> >>> >>> >>> >>> >>> I very much think that raising peoples expectations and being quite >>> >>> ambitious about what to expect is an important part of this. Of cou= rse >>> >>> 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 ba= d >>> >>> results when we see them is reasonable! >>> >> >>> >> Okay so this would turn into: >>> >> >>> >> base latency to base latency + 30 ms: gree= n >>> >> 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=C3=A4ht >>> Open Networking needs **Open Source Hardware** >>> >>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >> >> >> _______________________________________________ >> 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