From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B94E821F1F7 for ; Tue, 28 Apr 2015 01:39:08 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MDi9C-1YW1L53QC6-00HAfK; Tue, 28 Apr 2015 10:38:57 +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: Tue, 28 Apr 2015 10:38:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07C4C7B3-80BA-4106-9263-E86E652FC5AC@gmx.de> References: <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> <1D70AD75-F177-4146-A4D6-2FD6DB408B63@gmx.de> To: David Lang X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:1Mcg+fSGDhFry/O8IE/G0N0GoUDIBiBsIOfIgJGN99t7lI5DLXN DHE2dblA676BIGJzGRE+wzTF0viYlvWmhFvTYh5TgqbAxI7qqnmM8nWhY3cZ8j8wirbCXeQ QS0b98CfR6ZKgWWrGkYCv8DdTpqx1Glr0It8aHEPKXonP+18A4leSCaHD0RdgYGyQvnsL6A sI/KJ+3QAXJhzL/U5kYwQ== 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: Tue, 28 Apr 2015 08:39:37 -0000 Hi David, On Apr 28, 2015, at 10:01 , David Lang wrote: > On Tue, 28 Apr 2015, Sebastian Moeller wrote: >=20 >>>=20 >>> 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. >>=20 >> Ah, I think someone brought this up already, do we need to make = allowances for slow links? If a full packet traversal is already 16ms = can we really expect 30ms? And should we even care, I mean, a slow link = is a slow link and will have some drawbacks maybe we should just expose = those instead of rationalizing them away? On the other hand I tend to = think that in the end it is all about the cumulative performance of the = link for most users, i.e. if the link allows glitch-free voip while = heavy up- and downloads go on, normal users should not care one iota = what the induced latency actually is (aqm or no aqm as long as the link = behaves well nothing needs changing) >>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> Ah, and here is were I understand why my simplistic model from = above fails; induced latency will contribute significantly to jitter and = hence is a good proxy for link-suitability for real-time applications. = So I agree using the induced latency as measure to base the color bands = from sounds like a good approach. >>=20 >=20 > Voice is actually remarkably tolerant of pure latency. While 60ms of = jitter makes a connection almost unusalbe, a few hundred ms of = consistant latency isn't a problem. IIRC (from my college days when ATM = was the new, hot technology) you have to get up to around a second of = latency before pure-consistant latency starts to break things. Well, what I want to see is a study, preferably psychophysics = not modeling ;), showing the different latency =93tolerances=94 of = humans. I am certain that humans can adjust to even dozens of seconds = de;ays if need be, but the goal should be fluent and seamless = conversation not interleaved monologues. Thanks for giving a bound for = jitter, do you have any reference for perceptional jitter thresholds or = some such? >=20 > Gaming and high frequency trading care about the minimum latency a = LOT. but most other things are far more sentitive to jitter than pure = latency. [1] Sure, but it is easy to =93loose=94 latency but impossible to = reclaim, so we should aim for lowest latency ;) . Now as long as jitter = has a bound one can trade jitter for latency, by simply buffering more = at the receiver thereby ironing out (a part of the) the jitter while = introducing additional latency. One reason why I still thing that = absolute latency thresholds have some value as they would allow to = assess how much of a =93budget=94 one has to flatten out jitter, but I = digress. I also think now, that conflating absolute latency and buffer = bloat will not really help (unless everybody understands induced latency = by heart ;) )=85. >=20 > The trouble with bufferbloat induced latency is that it is highly = variable based on exactly how much other data is in the queue, so under = the wrong conditions, all latency caused by buffering shows up as = jitter. That is how I understood Dave=92s mail, thanks for confirming = that. Best Regards Sebastian >=20 > David Lang >=20 > [1] pure latency will degrade the experience for many things, but = usually in a fairly graceful manner. >=20