From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A01C221F15E for ; Wed, 28 Nov 2012 11:45:49 -0800 (PST) Received: from snappy-wlan.parc.xerox.com ([13.1.108.21]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TdnZn-0001do-Lh; Wed, 28 Nov 2012 19:45:44 +0000 Message-ID: <50B669E5.8020105@superduper.net> Date: Wed, 28 Nov 2012 11:45:41 -0800 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Greg White References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) Cc: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review 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: Wed, 28 Nov 2012 19:45:49 -0000 Not sure why you would use mean latency - for VoIP the thing that matters is maximum latency - if some packets are late, then you don't hear them. More precisely a small packet loss rate is OK, so you should use something like the 99th percentile of latency. In my last jitter buffer implementation I ran an estimator for 99th percentile latency, and added 5ms. That said, most jitter buffers in use are poor implementations, and introduce more latency than necessary. Simon On 11/28/2012 11:21 AM, Greg White wrote: > Jitter on its own is not useful for estimating VoIP quality. > > For (c), I've used: > > > > > > > > > > Cole, Robert G., and Joshua H. Rosenbluth. "Voice over IP performance > monitoring." ACM SIGCOMM Computer Communication Review 31, no. 2 (2001): > 9-24. > > Which I generally simplify to: > > > > > > > > > R= 94.2 - 0.024*Latency - 0.11*max(0,Latency-177.3 ms) - 30*log(1 + > 15*Loss). > > > > > > where Loss is mean packet loss rate (counting packets with latency > > (min_latency + 60ms) as lost), Latency is mean latency for packets not > counted as lost. > > > > > > > You can then translate R into an estimate of MOS using Eq.1 in the above > reference. > > -Greg > > > On 11/27/12 5:51 PM, "Toke Høiland-Jørgensen" wrote: > >> Oliver Hohlfeld >> writes: >> >>> The jitter measurements you have in mind will give you an idea on the >>> jitter specific to the chosen traffic scenario, nothing more --- and >>> in particular not the VoIP quality (although low vs. high jitter could >>> /indicate/ certain /possible/ quality degradations). >> >> Well no, in this sense the only "real" test for voip quality is picking >> up the (soft)phone and talking to someone. However, since the context >> here is automated measuring tools (preferably generating solid >> quantitative, comparable data), that is hardly feasible. >> >> I guess the goal of a comprehensive testing suite is to gather as many >> indicators of quality degradations (in the widest possible sense) as >> possible and testing for them under a variety of traffic conditions. I >> am by no means an expert on VoIP, but someone suggested measuring jitter >> could be useful, and I've proposed a possible way to do that (using >> iperf udp flows at a low-ish bandwidth). >> >> Since for the purpose of this particular discussion I seem to be in the >> test tool building business (at least for the time being), what I really >> need before going forward with this is someone to comment on (a) if >> using iperf udp flows is a valid way to measure jitter, (b) if measuring >> jitter is actually something someone wants to do and (c) if there are >> other tests that would be useful for testing VoIP (or general) >> conditions instead of / in addition to the jitter measurements. >> >> So far I don't have an answer to (a), only negative answers to (b) and >> nothing concrete for (c). So for the time being I'm shelving the idea, >> and will just note that it seems quite feasible to return to it should >> someone change their mind on (b) :) >> >> >> -Toke >> >> -- >> Toke Høiland-Jørgensen >> toke@toke.dk > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >