[Bloat] DSLReports Speed Test has latency measurement built-in

[Dave Taht]

1) I have 7 dual stack linode vm servers around the world you could
use - they are in england, japan, newark, atlanta, california, and one
other place. They are configured to use sch_fq (but I don't know what
is on the bare metal), and have other analysis tools on them, but you
would be welcome to use those.

2) There is a tcp socket option (something_lowat) which makes a big
difference in the amount of stuff that gets buffered in the lower
portions of the stack - would be useful in the server, and I think,
but am not sure, it is turned on in a few of the latest browsers on
some platforms. Stuart cheshire gave a talk about it recently that
should end up on youtube soon.

3) I like smokeping's plotting facility for more clearly showing the
range of outliers -

4) and do not cut things off at the 95 percentile, ever. 98% is more
reasonable - but I still prefer cdf plots to capture the entire range
of the data.

The analogy I use here is what if your steering wheel failed to
respond one time in 20 on your way to work - how long would you live?

(and then,  what if everyone's steering wheel failed one time in 20?)

Another way of thinking about it is what if your voip call went to
hell twice a minute?

On Mon, Apr 20, 2015 at 7:51 AM, David Lang <david at lang.hm> wrote:
> On Mon, 20 Apr 2015, jb wrote:
>
>> 2. The test does not do latency pinging on 3G and GPRS
>> because of a concern I had that with slower lines (a lot of 3G results are
>> less than half a megabit) the pings would make the speed measured
>> unreliable. And/or, a slow android phone would be being asked to do too
>> much. I'll do some tests with and without pinging on a 56kbit shaped line
>> and see if there is a difference. If there is not, I can enable it.
>
>
> remember that people can be testing from a laptop tethered to a phone.
>
>> 3. The graph of latency post-test is log X-axis at the moment
>> because one spike can render the whole graph almost useless with axis
>> scaling. What I might do is X-Axis breaking, and see if that looks ok.
>> Alternatively, a two panel graph, one with 0-200ms axis, the other in full
>> perspective. Or just live with the spike. Or scale to the 95% highest
>> number and let the other 5% crop. There are tool-tips after all to show
>> the
>> actual numbers.
>
>
> I think that showing the spike is significant because that latency spike
> would impact the user. It's not false data.
>
> showing two graphs may be the way to go.
>
> I don't think showing the 95th percentile is right. Again it is throwing
> away significant datapoints.
>
> I think summarizing the number as an average (with error bands) for each
> category of the test would be useful.
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

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