From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f98.google.com (mail-la0-f98.google.com [209.85.215.98]) (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 C4F8521F25E for ; Thu, 7 May 2015 06:26:45 -0700 (PDT) Received: by labmn9 with SMTP id mn9so1051630lab.0 for ; Thu, 07 May 2015 06:26:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=y6Mtet+1PkqQktGzDuL91DkHNuHTkFUaol34W13oE40=; b=Jkzh+sSi2qJgLoKOaa8bCnUTRekQCf9FlIrsNZOxMDFRnA3WH5YAXC6+ynO4u6NMhl HTDfZC53O+kn7HCPZxM9LjbXRLAYcbGwaPylkQv19SWr+6VqzZENjrs0lLcTEMnPYfko RiicrmwtioPTX8ySMIQscl4EuzHb3z6qilygoNM0iIHejkWDvrzMy7m7n1zu5oUi307S 7dsvrrH1rIpxGpOnwyK29A6vmkO+Q1vW/Hax/4P1riseIJsxZaYI+BBpAIwKNoupM4Np E0OdYaT3o9i3NYzkPcdvAH+nZUOeDemyKfOtAIK9dZm3dkUwq/PD9zoWAxjoPsDd7+1y wZ8w== X-Gm-Message-State: ALoCoQnmdfcEv4E4KQMeifs58YqtBHhgb07/o4VDdZC0FzfqjDUuo1a4TMRsRT/CtrohdBszFj5UMTUMph/Z0nbT44yajsdRxw== X-Received: by 10.180.82.6 with SMTP id e6mr670131wiy.84.1431005202736; Thu, 07 May 2015 06:26:42 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog122.obsmtp.com. [207.126.144.153]) by mx.google.com with SMTPS id bc1sm157694wjc.1.2015.05.07.06.26.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 06:26:42 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob122.postini.com ([207.126.147.11]) with SMTP ID DSNKVUtoEbY3lMEncyyEZcn7OneHngqEU03s@postini.com; Thu, 07 May 2015 13:26:41 UTC Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1YqLon-0001dZ-5i; Thu, 07 May 2015 14:26:25 +0100 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YqLov-0000Hz-PA; Thu, 07 May 2015 13:26:33 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_4249D92E-A33C-4CF7-B93A-13504863AA06" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Thu, 7 May 2015 14:26:43 +0100 Message-Id: <9BFBC2DA-7180-40CB-A145-4E93AC2A9529@pnsol.com> 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> To: jb X-Mailer: Apple Mail (2.1878.6) 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:27:14 -0000 --Apple-Mail=_4249D92E-A33C-4CF7-B93A-13504863AA06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 May 2015, at 14:14, jb wrote: > I thought would be more sane too. I see mentioned online that PDV is a=20= > gaussian distribution (around mean) but it looks more like half a bell = curve, with most numbers near the the lowest latency seen, and getting = progressively worse with > less frequency. That's someone describing the typical mathematical formulation = (motivated by noise models in signal propagation) not the reality = experienced over DSL links > At least for DSL connections on good ISPs that scenario seems more = frequent. > You "usually" get the best latency and "sometimes" get spikes or fuzz = on top of it. "Good ISPs" (let's, for the moment define good this way) are ones in = which the variability induced by transit accross them is small and = bounded - BT Wholesale (access network) has - in our experience - = delivers packets (after you've removed the effects of distance and = packet size) from the customer to the retail ISP with <5ms delay = variation (~0%loss) and from the retail ISP to the customer <15ms delay = variation <0.1% loss. The delay appears to be uniformly distributed. The major (in such a scenario) cause of delay/loss is the instantaneous = overdriving of the last mile capacity - that takes the typical pattern = of rapid growth followed by slow decay that would expected for a queue = fill/empty cycle at that point in the network (in that case the BRAS) An example (not quite what described above - but one that illustrates = the isssues) can be found here; = http://www.slideshare.net/mgeddes/advanced-network-performance-measurement= Neil >=20 > by the way after I posted I discovered Firefox has an issue with this = test so I had > to block it with a message, my apologies if anyone wasted time trying = it with FF. > Hopefully i can figure out why. >=20 >=20 > On Thu, May 7, 2015 at 9:44 PM, Mikael Abrahamsson = wrote: > On Thu, 7 May 2015, jb wrote: >=20 > There is a web socket based jitter tester now. It is very early stage = but > works ok. >=20 > http://www.dslreports.com/speedtest?radar=3D1 >=20 > 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). >=20 > 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. >=20 > Apart from that, the above multi-place RTT test is really really nice, = thanks for doing this! >=20 >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_4249D92E-A33C-4CF7-B93A-13504863AA06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 7 May 2015, at 14:14, jb <justin@dslr.net> wrote:

I thought would be more sane too. I see mentioned online = that PDV is a 
gaussian distribution (around mean) but it looks = more like half a bell curve, with most numbers near the the lowest = latency seen, and getting progressively worse with
less = frequency.

That's someone = describing the typical mathematical formulation (motivated by noise = models in signal propagation) not the reality experienced over DSL = links

At least = for DSL connections on good ISPs that scenario seems more = frequent.
You "usually" get the best latency and "sometimes" = get spikes or fuzz on top of = it.

"Good ISPs" (let's, for = the moment define good this way) are ones in which the variability = induced by transit accross them is small and bounded - BT Wholesale = (access network) has - in our experience - delivers packets (after = you've removed the effects of distance and packet size) from the = customer to the retail ISP with <5ms delay variation (~0%loss) and = from the retail ISP to the customer <15ms delay variation <0.1% = loss. The delay appears to be uniformly = distributed.

The major (in such a scenario) = cause of delay/loss is the instantaneous overdriving of the last mile = capacity - that takes the typical pattern of rapid growth followed by = slow decay that would expected for a queue fill/empty cycle at that = point in the network (in that case the BRAS)

An = example (not quite what described above - but one that illustrates the = isssues) can be found here; http://www.slideshare.net/mgeddes/advanced-network-performance-m= easurement

Neil


by the way after I = posted I discovered Firefox has an issue with this test so I = had
to block it with a message, my apologies if anyone wasted = time trying it with FF.
Hopefully i can figure out = why.


On Thu, May 7, 2015 at 9:44 PM, 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 = 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
= --Apple-Mail=_4249D92E-A33C-4CF7-B93A-13504863AA06--