From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 AF52F21F14D for ; Fri, 24 Apr 2015 23:03:17 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOOJl-1YiKPt1w4z-005sIf; Sat, 25 Apr 2015 08:03:12 +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: <14ceed3c818.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> Date: Sat, 25 Apr 2015 08:03:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Simon Barber X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:9UmiZYi1LFtDnCnWVkZ/9uHK2w0pzykZEXlLByBLzj+e/SKh4Ex OxafaGdBaKvy696H8isOZdcjnhHqGRUM7Ah3hyPHnhDLN7CpeUakTXIPJUc0SlB6nEEXeAK 38KgJjlL2NbdX78BTT7kOyu6WuO0Or/cK1bp/Rr12V9OyD/+2RC9qZaaJEjbqzB0JfTVGRZ b7yMVVvLqCLlixS5TFVPA== 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: Sat, 25 Apr 2015 06:03:46 -0000 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 = literature citations to back them up, as they are way shorter than what = the ITU recommends for one-way-latency (see ITU-T G.114, Fig. 1). I am = not "married=94 to the ITU numbers but I think we should use generally = accepted numbers here and not bake our own thresholds (and for all I = know your numbers are fine, I just don=92t know where they are coming = from ;) ) Best Regards Sebastian >=20 > Simon >=20 > Sent with AquaMail for Android > http://www.aqua-mail.com >=20 >=20 > On April 24, 2015 9:04:45 PM Dave Taht wrote: >=20 >> 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. >>=20 >> Please see my earlier email laying out the bands. And gettys' = manifesto. >>=20 >> 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. >>=20 >>=20 >> 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. The only way to detect whether a conversation is natural is if = users notice, I would say... >> > 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=F8iland-J=F8rgensen = wrote: >> >> >> >>> Sebastian Moeller writes: >> >>> >> >>>> I know this is not perfect and the numbers will probably require >> >>>> severe "bike-shedding=94 >> >>> >> >>> 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 >>=20 >>=20 >>=20 >> -- >> Dave T=E4ht >> Open Networking needs **Open Source Hardware** >>=20 >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat