From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 3FA8221F32E for ; Wed, 6 May 2015 21:29:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 43F8FA1; Thu, 7 May 2015 06:29:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1430972975; bh=gI2h2ylOE2FG2JuwBgjtjoJTIClhoWchajyrzdm63Ig=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pFCSbb38gfVeWLHl54xIRaffv/WwwXhZLMcYm4TeLooRktgaeQFtYtNhSw+LpJmSy CAoEa3g7XI9Unjo4Lyu7Vcl7PnqD3qd8npFwFdt5Xn6zWnL8I9Yz6F7ybtLEhqXPz3 08ptkaUWTXAwnKQLGQ6qUAWhM3r9OovvklD0avPk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3D4759F; Thu, 7 May 2015 06:29:35 +0200 (CEST) Date: Thu, 7 May 2015 06:29:35 +0200 (CEST) From: Mikael Abrahamsson To: Jonathan Morton In-Reply-To: Message-ID: References: <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> <5549A1B8.50005@superduper.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW 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: Thu, 07 May 2015 04:30:07 -0000 X-List-Received-Date: Thu, 07 May 2015 04:30:07 -0000 X-List-Received-Date: Thu, 07 May 2015 04:30:07 -0000 On Wed, 6 May 2015, Jonathan Morton wrote: > So, as a proposed methodology, how does this sound: > > Determine a reasonable ballpark figure for typical codec and jitter-buffer > delay (one way). Fix this as a constant value for the benchmark. Commercial grade VoIP systems running in a controlled environment typically (in my experience) come with 40ms PDV (Packet Delay Variation, let's not call it jitter, the timing people get upset if you call it jitter) buffer. These systems typically do not work well over the Internet as we here all know, 40ms is quite low PDV on a FIFO based Internet access. Applications actually designed to work on the Internet have PDV buffers that adapt according to what PDV is seen, and so they can both increase and decrease in size over the time of a call. I'd say ballpark reasonable figure for VoIP and video conferencing of reasonable PDV is in the 50-100ms range or so, where lower of course is better. It's basically impossible to have really low PDV on a 1 megabit/s link because a full size 1500 byte packet will take close to 10ms to transmit, but it's perfectly feasable to keep it under 10-20ms when the link speed increases. If we say that 1 megabit/s (typical ADSL up speed)is the lower bound of speed where one can expect VoIP to work together with other Internet traffic, then 50-100ms should be technically attainable if the vendor/operator actually tries to reduce bufferbloat/PDV. > Measure the maximum induced delays in each direction. Depending on the length of the test, it might make sense to aim for 95th or 99th percentile, ie throw away the one or few worst values as these might be outliers. But generally I agree with your proposed terminology. -- Mikael Abrahamsson email: swmike@swm.pp.se