From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D09E82022C0 for ; Thu, 7 May 2015 04:37:06 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lbi2Z-1ZVSUg3U9T-00lDGE; Thu, 07 May 2015 13:37:01 +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 13:36:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <674F2829-0B1C-4FE0-A0F8-264E0F3CED57@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> <9CF0E173-2CE5-4950-84D1-44EAEF174882@gmx.de> To: jb X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:s3q/51GTj/ppaH2UasvEaAbD1nM3ces5oEbs/Q/Eh1xh8SYp8j/ jlQyecZgaM1GE/QKi8cmNRyW+OcLb+K8Yrx9N88dd1lZzGALHcYDqwQljf9dAHVHYgulrZT 0DXMAaur6Dwvo8OwoGu93avFxGI6g0Y5NMIMHTfmj1aMnfXTeIiKUpgD6dxQkAZY9ubshOa 6SSSVyBS0oPCMY5p3n/9g== X-UI-Out-Filterresults: notjunk:1; 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 11:37:35 -0000 Hi jb, On May 7, 2015, at 12:44 , jb wrote: > 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 Looks great. >=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=20 > that same rolling buffer. It is quite similar to the std.dev actually = (not shown). So it takes RTT(N+1) - RTT(N)? But if due to buffer bloat the = latency goes up for several 100s of MS or several seconds would this not = register as low PDV? Would it not be better to take the difference withe = the minimum? And maybe even remember the minimum for a longer period = than 60 seconds? I guess no network path is guaranteed to be stable over = time, but if re-routing is rare, maybe even keep the same minimum as = long as the tool is running? You could still report some aggregate, like = the mean deviation of the sample buffer, but just not taking the = difference between consecutive samples (which sort of feels like rater = giving the change in PDV than PDV itself, but as always I am a layman in = these matters)... >=20 > Anyway because it is talking to 21 servers or whatever it is not doing = high > frequency pinging, I think its about 2hz per server (which is about 50 = packets > per second and not much bandwidth).=20 >=20 > My thought is one might click on a server and focus in on that, That sounds pretty useful, especially giving the already = relative broad global coverage ;) > then it could go to a higher frequency. Since it is still TCP, I've = got lingering=20 > doubts that simulating 20ms stream with tcp bursts is the same as UDP, > definitely in the case of packet loss, it would not be.' >=20 > There is no way to "load" your connection from this tool, you could = open another > page and run a speed test of course. Could this be used to select a server for the bandwidth test? Best Regards Sebastian >=20 > I'm still working on it, but since you guys are talking RTT and Jitter = thought I'd > throw it into the topic. >=20 > On Thu, May 7, 2015 at 7:16 PM, Mikael Abrahamsson = wrote: > On Thu, 7 May 2015, Sebastian Moeller wrote: >=20 > 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? >=20 > The 40ms is fairly typical for what I encountered 10 years ago. To = deploy them there was a requirement to have QoS (basically low-latency = queuing on Cisco) for DSCP EF traffic, otherwise things didn't work on = the 0.5-2 megabit/s connections that were common back then. >=20 > I'd say anything people are trying to deploy now for use on the = Internet without QoS, 40ms just won't work and has never really worked. = You need adaptive PDV-buffers and they need to be able to handle = hundreds of ms of PDV. >=20 > If you look at this old document from Cisco (10 years old): >=20 > http://www.ciscopress.com/articles/article.asp?p=3D357102 >=20 > "Voice (Bearer Traffic) >=20 > The following list summarizes the key QoS requirements and = recommendations for voice (bearer traffic): >=20 > Voice traffic should be marked to DSCP EF per the QoS Baseline and RFC = 3246. >=20 > Loss should be no more than 1 percent. >=20 > One-way latency (mouth to ear) should be no more than 150 ms. >=20 > Average one-way jitter should be targeted at less than 30 ms. >=20 > A range of 21 to 320 kbps of guaranteed priority bandwidth is required = per call (depending on the sampling rate, the VoIP codec, and Layer 2 = media overhead). >=20 > Voice quality directly is affected by all three QoS quality factors: = loss, latency, and jitter." >=20 > This requirement kind of reflects the requirements of the VoIP systems = of the day with 40ms PDV buffer. There is also a section a page down or = so about "Jitter buffers" where there is a recommendation to have = adaptive jitter buffers, which I didn't encounter back then but I really = hope is a lot more common today. >=20 >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20