From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 94C6221F285 for ; Thu, 7 May 2015 00:08:49 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so36428835ied.1 for ; Thu, 07 May 2015 00:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VICgdOA5oDDnyseJ7IRHRFG02VG9SMBoizVh1FhMBV0=; b=v99i9/jhl67ZGTBaU2lCfw7bhHKJnzkuaU8LubLK6bFDVgnhSjgMW9UGdCpYGlwE/B GH/KOIfG0U7EL9yHJUam/VQMytDwt5zwI/uHsrSD42WxMMvxC4UDfGFPaI89NNIN1n8x 2l0mF8cK03luPLM+lGCeaqzU/381lOLR03A3r8mbIl5/R+KxvQjtXvx/ovmh24IXof4h Omet1V27KKShxOec5MHthtezjlp+m8agbsbDW8IW9pwZOLdDNrdc/P+9VqlzlsCBiabj H1CVUtKCF+qIQ2RQhveFTIpL3pDBPil391E1EtwnlY7dxIj6kTTeWO4LeEd8EIDbqRTL x0tg== MIME-Version: 1.0 X-Received: by 10.107.169.160 with SMTP id f32mr2931873ioj.83.1430982527343; Thu, 07 May 2015 00:08:47 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Thu, 7 May 2015 00:08:47 -0700 (PDT) In-Reply-To: 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> Date: Thu, 7 May 2015 17:08:47 +1000 X-Google-Sender-Auth: 9tkrwnxD6rILNFDovu6yc9-0vPE Message-ID: From: jb To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1142646c390bf8051578955d 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:09:17 -0000 --001a1142646c390bf8051578955d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am working on a multi-location jitter test (sorry PDV!) and it is showing a lot of promise. For the purposes of reporting jitter, what kind of time measurement horizon is acceptable and what is the +/- output actually based on, statistically ? For example - is one minute or more of jitter measurements, with the +/- being the 2rd std deviation, reasonable or is there some generally accepted definition ? ping reports an "mdev" which is SQRT(SUM(RTT*RTT) / N =E2=80=93 (SUM(RTT)/N)^2) but I've seen jitter defined as maximum and minimum RTT around the average however that seems very influenced by one outlier measurement. thanks On Thu, May 7, 2015 at 2:29 PM, Mikael Abrahamsson wrote= : > 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-buff= er >> 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 Interne= t > as we here all know, 40ms is quite low PDV on a FIFO based Internet acces= s. > 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 a= nd > 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)i= s > 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 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a1142646c390bf8051578955d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am working on a multi-location jitter test (sorry PDV!) = and it is showing a lot of promise.
For the purposes of reporting jitte= r, what kind of time measurement horizon is acceptable=C2=A0
and = what is the +/- output actually based on, statistically ?

For example - is one minute or more of jitter measurements, with th= e +/- being
the 2rd std deviation, reasonable or is there some ge= nerally accepted definition ?

ping reports an "mdev" which= is
SQRT(SUM(RTT*RTT) / N =E2=80=93 (SUM(RTT)/N)^2)
but I've seen= jitter defined as maximum and minimum RTT around the average
however th= at seems very influenced by one outlier measurement.

thanks

On Thu, Ma= y 7, 2015 at 2:29 PM, Mikael Abrahamsson <swmike@swm.pp.se> w= rote:
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<= br> 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 n= ot call it jitter, the timing people get upset if you call it jitter) buffe= r. These systems typically do not work well over the Internet as we here al= l 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 acco= rding to what PDV is seen, and so they can both increase and decrease in si= ze over the time of a call.

I'd say ballpark reasonable figure for VoIP and video conferencing of r= easonable PDV is in the 50-100ms range or so, where lower of course is bett= er. It's basically impossible to have really low PDV on a 1 megabit/s l= ink because a full size 1500 byte packet will take close to 10ms to transmi= t, but it's perfectly feasable to keep it under 10-20ms when the link s= peed increases. If we say that 1 megabit/s (typical ADSL up speed)is the lo= wer bound of speed where one can expect VoIP to work together with other In= ternet traffic, then 50-100ms should be technically attainable if the vendo= r/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=C2=A0 =C2=A0 email: swmike@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat

--001a1142646c390bf8051578955d--