<div dir="ltr">Regarding ping during the test, although it isn't ideal, it appears<div>to be enough to identify problems, and also consistently get the same</div><div>grade, to within one grade level anyway.</div><div><br></div><div>An "A" or "A+" is not going to get a "C", and a "D" or "F" is never</div><div>going to get a "B" no matter how many times the test is re-run.</div><div><br></div><div>(Regarding the transition between idle and downloading, the</div><div>downloads are phased in, not all started at once so any conclusion</div><div>on transition response has to take that into account as well).</div><div><br></div><div>I can increase the ping frequency when the connection is seen as</div><div>fast, but 100hz or 10hz would have issues, for one, there is no</div><div>visibility into whether a browser is using tcp push, and for another,</div><div>doing 10 or 100 a second - if they turn into packets - takes a lot of </div><div>capacity out of the upload channel. If they coalesce then the</div><div>measurements just add noise to the result.</div><div><br></div><div>My hope is the test evolves but is balanced, leading to pointers on</div><div>problems that may require other more specialised tests to fully</div><div>explore. It has taken almost half a million tests to mostly avoid buggy</div><div>browser versions and platforms, and get a repeatable and largely</div><div>correct speed measurement. In a clean lab network after</div><div>a dozen tests that phase of things would be over with and done.</div><div><br></div><div>I hope there can be a user settable option for getting finer view</div><div>of latency under load. Or another tool designed just for it.</div><div>I don't see any issue with a solid desktop PC running a current</div><div>browser, connected to a server dedicated to listening emitting a</div><div>10hz-100hz web socket ping while also doing a bunch of</div><div>downloads, if that was the entire purpose of the exercise.</div><div><br></div><div>In the mean time I'd like to add a way to allow a user to easily</div><div>tag the equipment they are using because at the moment we're</div><div>getting all this useful grade information without any context. We don't</div><div>even know which home users have made an attempt to ameliorate</div><div>problems.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 3, 2015 at 2:25 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In one of the threads I saw that the dslreports test is one http ping<br>
every second. I am not really sure how that is handled - if the<br>
connection is<br>
tcp (?) and persistent, that measures 1 packet RTT, if it is a new<br>
connection, it is quite a few RTTs.<br>
<br>
And it is really not enough pings for valid statistical sampling.<br>
<br>
IF tcp, It would be vastly better to attempt a tcp ping every 10ms on<br>
an established connection (or whatever can be achieved, with 20ms<br>
being a good interval for most voip, 100ms seems easily doable,<br>
but...). This would accomplish two things:<br>
<br>
1) A single packet loss would not cause a RTO (usually 250ms) but be<br>
flushed out (resent) on the next packet sent. So you would see replies<br>
get bunched in relation to loss and delay.<br>
<br>
2) More pings more accurately track actual latency over a much tighter<br>
interval in general, particularly during the slow start phases at the<br>
beginning of the test where things tend to get really out of hand when<br>
you fire up tons of flows.<br>
<br>
In terms of plotting, I am quite fond of smokeping's methods, so you<br>
could still show the bar chart on a per second basis, but colored as<br>
per smokeping.<br>
<br>
(It had been my hope to one day leverage the webrtc apis to be able to<br>
test udp.)<br>
<br>
On what interval is it feasible to fire off a new http ping, and can<br>
the difference between a persistent connection and a new one be<br>
determined from within the browser?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Dave Täht<br>
Open Networking needs **Open Source Hardware**<br>
<br>
<a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
</font></span></blockquote></div><br></div>