From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 EB0C521F2B1 for ; Thu, 7 May 2015 00:40:26 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MJSQ7-1YnFLa29b1-0032TI; Thu, 07 May 2015 09:40:21 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 7 May 2015 09:40:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CF0E173-2CE5-4950-84D1-44EAEF174882@gmx.de> 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> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:hweUYzJp5tQaD/x/EcdlYxaS0CIkEJWSYZ2Ju1HzGNXf63WbDLa hYOwm9LThj7jbwkSk8JQBTK3vNp1FPN0kfBBLQzFay8yBe76AXUUhxyNl14NeqRmv+03xal f6C99G+ce+PcbYWcjQ16YCUKp0sZLh9bTcJJFjDIwhQViPgQPTBl/KNMY6IhiBndOleXeq3 ooHDv+ijopHpkwtWwTUTg== X-UI-Out-Filterresults: notjunk:1; Cc: Jonathan Morton , 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:40:56 -0000 Hi Mikhael, On May 7, 2015, at 09:24 , Mikael Abrahamsson wrote: > On Thu, 7 May 2015, Jonathan Morton wrote: >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. Is this 40ms sort of set in stone? If so we have a new indicator = for bad buffer-bloat if inured latency > 40 ms link is unsuitable for = decent voip (using old equipment). Is the newer voip stuff that telcos = roll out currently any smarter? Best Regards Sebastian >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat