From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 F107821F294 for ; Sat, 2 May 2015 16:24:15 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so62177329igb.0 for ; Sat, 02 May 2015 16:24:14 -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=VNn6Ztl5W5Giu6RTzl0iMWlNK/bbsvPx4qiviqI/ia0=; b=sL9hKXV9QKahFkGd2BIwBM5dP7Ty2TIQttbi45oJoLACkE/cgA2v2gzIrfuOyhm5SM JV0UvM5Lpdv/WcIKzl23hFmSeLZoRK7O9L5Nn8UafhnHGy0+caYaG6GkYzroIYN2UQ0a HA10dTLC39MD0JKp87s1HINzmcrSBZZYnQbwP1rchHK8tyjB1mVbgTtzMcuygny7ZDGi Lo8TK4215Yd+SmHTHMAHXX/gsogNUm9K9jmhr/a9pPpwJsS1Mrmv2JzRESEz4l3vOj06 jSYcw4rPny793+E83i4yLMt1H9ZFuEFVbtSR0I0kUnb5MKw219QA+R8zko4EKjgtK+wp uDQA== MIME-Version: 1.0 X-Received: by 10.42.129.73 with SMTP id p9mr21187535ics.48.1430609054642; Sat, 02 May 2015 16:24:14 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Sat, 2 May 2015 16:24:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 May 2015 09:24:14 +1000 X-Google-Sender-Auth: HrsdWZSqchR9VSkTAeAg439teXA Message-ID: From: jb To: Dave Taht Content-Type: multipart/alternative; boundary=20cf301af6d983b8cd051521a02a Cc: bloat Subject: Re: [Bloat] dslreports ping every second? 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: Sat, 02 May 2015 23:24:44 -0000 --20cf301af6d983b8cd051521a02a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding ping during the test, although it isn't ideal, it appears to be enough to identify problems, and also consistently get the same grade, to within one grade level anyway. An "A" or "A+" is not going to get a "C", and a "D" or "F" is never going to get a "B" no matter how many times the test is re-run. (Regarding the transition between idle and downloading, the downloads are phased in, not all started at once so any conclusion on transition response has to take that into account as well). I can increase the ping frequency when the connection is seen as fast, but 100hz or 10hz would have issues, for one, there is no visibility into whether a browser is using tcp push, and for another, doing 10 or 100 a second - if they turn into packets - takes a lot of capacity out of the upload channel. If they coalesce then the measurements just add noise to the result. My hope is the test evolves but is balanced, leading to pointers on problems that may require other more specialised tests to fully explore. It has taken almost half a million tests to mostly avoid buggy browser versions and platforms, and get a repeatable and largely correct speed measurement. In a clean lab network after a dozen tests that phase of things would be over with and done. I hope there can be a user settable option for getting finer view of latency under load. Or another tool designed just for it. I don't see any issue with a solid desktop PC running a current browser, connected to a server dedicated to listening emitting a 10hz-100hz web socket ping while also doing a bunch of downloads, if that was the entire purpose of the exercise. In the mean time I'd like to add a way to allow a user to easily tag the equipment they are using because at the moment we're getting all this useful grade information without any context. We don't even know which home users have made an attempt to ameliorate problems. On Sun, May 3, 2015 at 2:25 AM, Dave Taht wrote: > In one of the threads I saw that the dslreports test is one http ping > every second. I am not really sure how that is handled - if the > connection is > tcp (?) and persistent, that measures 1 packet RTT, if it is a new > connection, it is quite a few RTTs. > > And it is really not enough pings for valid statistical sampling. > > IF tcp, It would be vastly better to attempt a tcp ping every 10ms on > an established connection (or whatever can be achieved, with 20ms > being a good interval for most voip, 100ms seems easily doable, > but...). This would accomplish two things: > > 1) A single packet loss would not cause a RTO (usually 250ms) but be > flushed out (resent) on the next packet sent. So you would see replies > get bunched in relation to loss and delay. > > 2) More pings more accurately track actual latency over a much tighter > interval in general, particularly during the slow start phases at the > beginning of the test where things tend to get really out of hand when > you fire up tons of flows. > > In terms of plotting, I am quite fond of smokeping's methods, so you > could still show the bar chart on a per second basis, but colored as > per smokeping. > > (It had been my hope to one day leverage the webrtc apis to be able to > test udp.) > > On what interval is it feasible to fire off a new http ping, and can > the difference between a persistent connection and a new one be > determined from within the browser? > > > -- > Dave T=C3=A4ht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > --20cf301af6d983b8cd051521a02a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding ping during the test, although it isn't idea= l, it appears
to be enough to identify problems, and also consistently = get the same
grade, to within one grade level anyway.
<= br>
An "A" or "A+" is not going to get a &quo= t;C", and a "D" or "F" is never
going to= get a "B" no matter how many times the test is re-run.

(Regarding the transition between idle and downloading, the=
downloads are phased in, not all started at once so any conclusi= on
on transition response has to take that into account as well).=

I can increase the ping frequency when the connec= tion is seen as
fast, but 100hz or 10hz would have issues, for on= e, there is no
visibility into whether a browser is using tcp pus= h, and for another,
doing 10 or 100 a second - if they turn into = packets - takes a lot of=C2=A0
capacity out of the upload channel= . If they coalesce then the
measurements just add noise to the re= sult.

My hope is the test evolves but is balanced,= leading to pointers on
problems that may require other more spec= ialised tests to fully
explore. It has taken almost half a millio= n tests to mostly avoid buggy
browser versions and platforms, and= get a repeatable and largely
correct speed measurement. In a cle= an lab network after
a dozen tests that phase of things would be = over with and done.

I hope there can be a user set= table option for getting finer view
of latency under load. Or ano= ther tool designed just for it.
I don't see any issue with a = solid desktop PC running a current
browser, connected to a server= dedicated to listening emitting a
10hz-100hz web socket ping whi= le also doing a bunch of
downloads, if that was the entire purpos= e of the exercise.

In the mean time I'd like t= o add a way to allow a user to easily
tag the equipment they are = using because at the moment we're
getting all this useful gra= de information without any context. We don't
even know which = home users have made an attempt to ameliorate
problems.

On Sun, May 3, = 2015 at 2:25 AM, Dave Taht <dave.taht@gmail.com> wrote:
In one of the threads I saw that the dslrep= orts test is one http ping
every second. I am not really sure how that is handled - if the
connection is
tcp (?) and persistent, that measures 1 packet RTT, if it is a new
connection, it is quite a few RTTs.

And it is really not enough pings for valid statistical sampling.

IF tcp, It would be vastly better to attempt a tcp ping every 10ms on
an established connection (or whatever can be achieved, with 20ms
being a good interval for most voip, 100ms seems easily doable,
but...). This would accomplish two things:

1) A single packet loss would not cause a RTO (usually 250ms) but be
flushed out (resent) on the next packet sent. So you would see replies
get bunched in relation to loss and delay.

2) More pings more accurately track actual latency over a much tighter
interval in general, particularly during the slow start phases at the
beginning of the test where things tend to get really out of hand when
you fire up tons of flows.

In terms of plotting, I am quite fond of smokeping's methods, so you could still show the bar chart on a per second basis, but colored as
per smokeping.

(It had been my hope to one day leverage the webrtc apis to be able to
test udp.)

On what interval is it feasible to fire off a new http ping, and can
the difference between a persistent connection and a new one be
determined from within the browser?


--
Dave T=C3=A4ht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

--20cf301af6d983b8cd051521a02a--