From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (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 E0E2D21F1FB for ; Thu, 7 May 2015 06:10:11 -0700 (PDT) Received: by vnbf62 with SMTP id f62so3033550vnb.3 for ; Thu, 07 May 2015 06:10:09 -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=+mjWnbSlZT86w392tRntsD89fLKcgmAQDmYJYa6UNbo=; b=J0oQPRX5ynXPAK17BDfn2po0t9159yTGb4v6TxRtKWwQdHJLo9KjsiBSTi32dg7Nau u/KAdWPMY2sPGtB+zV/+Ggdu9PmxEdRrvQKtTO5nCJZq5Ii8aCyE92qRpgJIUGVmHrD8 qGhBb8M0fjoctRU7IKRlE9NI62yZg2knLJGlKs2hPmI6hKDRJBy//4I4hMmj61O+twHG 2EHKJsNWB9zQYVRzfluLVFka80AI+aGinxhEBITVuJXLOuNH2akHF3oMy+qvtoKNqLfD Viqrg+PF1ehGLvPjlDlXjqY/19KBavov7owj21NkB8NOlrwtv26JEoQRZYHHy/WloOcj BddQ== MIME-Version: 1.0 X-Received: by 10.52.92.20 with SMTP id ci20mr2928878vdb.54.1431004209791; Thu, 07 May 2015 06:10:09 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.52.21.44 with HTTP; Thu, 7 May 2015 06:10:09 -0700 (PDT) In-Reply-To: References: <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> <9CF0E173-2CE5-4950-84D1-44EAEF174882@gmx.de> Date: Thu, 7 May 2015 09:10:09 -0400 X-Google-Sender-Auth: mRcxiiRfEV8etS8jrBHpNT_Igco Message-ID: From: Jim Gettys To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec501626998cec005157da19a 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 13:10:41 -0000 --bcaec501626998cec005157da19a Content-Type: text/plain; charset=UTF-8 What I don't know is how rapidly VOIP applications will adjust their latency + jitter window (the operating point that they choose for their operation). They can't adjust it instantly, as if they do, the transitions from one operating point to another will cause problems, and you certainly won't be doing that adjustment quickly. So the time period over which one computes jitter statistics should probably be related to that behavior. Ideally, we need to get someone involved in WebRTC to help with this, to present statistics that may be useful to end users to predict the behavior of their service. I'll see if I can get someone working on that to join the discussion. - Jim On Thu, May 7, 2015 at 7:44 AM, Mikael Abrahamsson wrote: > On Thu, 7 May 2015, jb wrote: > > There is a web socket based jitter tester now. It is very early stage but >> works ok. >> >> http://www.dslreports.com/speedtest?radar=1 >> >> So the latency displayed is the mean latency from a rolling 60 sample >> buffer, Minimum latency is also displayed. and the +/- PDV value is the >> mean difference between sequential pings in that same rolling buffer. It is >> quite similar to the std.dev actually (not shown). >> > > So I think there are two schools here, either you take average and display > + / - from that, but I think I prefer to take the lowest of the last 100 > samples (or something), and then display PDV from that "floor" value, ie > PDV can't ever be negative, it can only be positive. > > Apart from that, the above multi-place RTT test is really really nice, > thanks for doing this! > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --bcaec501626998cec005157da19a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wha= t I don't know is how rapidly VOIP applications will adjust their laten= cy + jitter window (the operating point that they choose for their operatio= n).=C2=A0 They can't adjust it instantly, as if they do, the transition= s from one operating point to another will cause problems, and you certainl= y won't be doing that adjustment quickly.

So the time period over which one computes jitter stat= istics should probably be related to that behavior.

Ideally, we need to get someone involved in WebR= TC to help with this, to present statistics that may be useful to end users= to predict the behavior of their service.

I'll see if I can get someone working on that to join= the discussion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Jim


On Thu,= May 7, 2015 at 7:44 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 7 May= 2015, jb wrote:

There is a web socket based jitter tester now. It is very early stage but works ok.

http://www.dslreports.com/speedtest?radar=3D1

So the latency displayed is the mean latency from a rolling 60 sample buffe= r, Minimum latency is also displayed. and the +/- PDV value is the mean dif= ference between sequential pings in that same rolling buffer. It is quite s= imilar to the std.dev actually (not shown).

 So I think there are two schools here, either you take average and display = + / - from that, but I think I prefer to take the lowest of the last 100 sa= mples (or something), and then display PDV from that "floor" valu= e, ie PDV can't ever be negative, it can only be positive.

Apart from that, the above multi-place RTT test is really really nice, than= ks for doing this!


--
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

--bcaec501626998cec005157da19a--