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 48B4521F289 for ; Thu, 7 May 2015 00:24:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E342A1; Thu, 7 May 2015 09:24:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1430983457; bh=u4GnoUyiAz0ak6pjgvYTcy870VMrGokOtdw1BftowHE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BJN5xBwVWwTdvh0Yo99BB3FTAdiH0jY/NmgNcDymHcqyoz8pvLHWZJne4rGU4Vi+1 iyT20W/jz32xH9Z4pJfYWE8IQhZxqjHNRSKdlPgsSAHpPHsxKU2LdefsmdxYLIj7Ts KGMUaQxLOVDBjgI9VZZGLGRwrI9TQ9VxKlbKjuE0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 59FE79F; Thu, 7 May 2015 09:24:17 +0200 (CEST) Date: Thu, 7 May 2015 09:24:17 +0200 (CEST) From: Mikael Abrahamsson To: Jonathan Morton In-Reply-To: Message-ID: References: <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 07:24:55 -0000 On Thu, 7 May 2015, Jonathan Morton wrote: > However the more common characteristic is that delay is sometimes low > (link idle) and sometimes high (buffer full) and rarely in between. In > other words, delay samples are not statistically independent; loss due > to jitter is bursty, and real-time applications like VoIP can't cope > with that. For that reason, and due to your low temporal sampling rate, > you should take the peak delay observed under load and compare it to the > average during idle. Well, some applications will stop playing if the playout-buffer is empty, and if the packet arrives late, just start playing again and then increase the PDV buffer to whatever gap was observed, and if the PDV buffer has sustained fill, start playing it faster or skipping packets to play down the PDV buffer fill again. So you'll observe silence or cutouts, but you'll still hear all sound but after this event, your mouth-ear-mouth-ear delay has now increased. As far as I can tell, for instance Skype has a lot of different ways to cope with changing characteristics of the path, which work a lot better than a 10 year old classic PSTN-style G.711-over-IP style system with static 40ms PDV buffers, which behave exactly as you describe. -- Mikael Abrahamsson email: swmike@swm.pp.se