From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4AA0C21F21F for ; Tue, 28 Apr 2015 01:01:57 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t3S81aK0026911; Tue, 28 Apr 2015 01:01:48 -0700 Date: Tue, 28 Apr 2015 01:01:36 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Sebastian Moeller In-Reply-To: <1D70AD75-F177-4146-A4D6-2FD6DB408B63@gmx.de> Message-ID: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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:02:26 -0000 On Tue, 28 Apr 2015, Sebastian Moeller wrote: >> >> 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. > > 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) > >> >> 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. > > 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. > 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. 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] 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. David Lang [1] pure latency will degrade the experience for many things, but usually in a fairly graceful manner.