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

Sun Apr 19 06:20:05 EDT 2015

Hi Justin,

On Apr 19, 2015, at 07:26 , jb <justin at dslr.net> wrote:

> The graph below the upload and download is what is new.
> (unfortunately you do have to be logged into the site to see this)
> it shows the latency during the upload and download, color coded. (see attached image).

	This looks really good! The whole new test is great and reporting the latency numbers are the cherry on top.

	If there was a fairy around granting me three wishes restricted to your sppedtest’s latency portion (I know sort of the short end as far as wish-fairies go) I would ask for;
1) show the mean baseline latency as a line crossing all the bars, after all that is the best case and what we need to compare against to get the “under load” part from latency under load from.

2) To be able to asses the variability in the baseline I would ask for 95% confidence intervals around the baseline line. (Sure latencies are not normally distributed and hence neuter arithmetic mean nor confidence interval is the right thing to calculate from a statistics point of view, but at least they are relatively easy to understand, should be known to the users, and should still capture the gist of what is happening). The beauty of confidence intervals is that this allows to eye-ball the significance of the latency deviations under the two load conditions, if the bar does not fall into the 95% confidence interval, testing this value against the baseline distribution will turn out significant with p<= 0.05 in a t-test.

3) I would ask to never use a log scale, as this makes extreme outliers look better than they are so linear scale starting at 0 would be my wish here. People starting out from a high latency link will not b able willing to tolerate more latency increase under load than people on low latency links but rather they can only tolerate less latency increase if they still want decent VoIP or gaming experience, so reporting the latency under load as ratio of the unloaded latency would be counter productive. Reporting the latency under load as frequency (inverse of delay time) would be nice in that higher numbers denote a "better” link, but has the issue that it is going to be hard to quickly add different latency sources/components...

4) I know I only had three wishes, but measuring the latency while simultaneously saturating up- and download would be nice to test the worst case latency under load increase...

	I wonder is the latency test running against a different host than the bandwidth tests? If so are they using the same connection/port? (I just wonder whether fq_codel will hash the latency probe packets into different bins than the bandwidth packets).

Best Regards
	Sebastian

> 
> In your case during the upload it spiked to ~200ms from ~50ms but it was not so bad. During upload, there were no issues with latency.
> 
> I don't want to force anyone to sign up, just was making sure not to confuse anonymous users with more information than they knew what to do with. When I'm clear how to present the information, I'll make it available by default, to anyone member or otherwise.
> 
> Also, regarding your download, it stalled out completely for 5 seconds.. Hence the low conclusion as to your actual speed. It picked up to full speed again at the end. It basically went 
> 40 .. 40 .. 40 .. 40 .. 8 .. 8 .. 8 .. 40 .. 40 .. 40
> which explains why the Latency measurements in blue are not all high.
> A TCP stall? you may want to re-run or re-run with Chrome or Safari to see if it is reproducible. Normally users on your ISP have flat downloads with no stalls.
> 
> thanks
> -Justin
> 
>  
> On Sun, Apr 19, 2015 at 2:01 PM, Dave Taht <dave.taht at gmail.com> wrote:
> What I see here is the same old latency, upload, download series, not
> latency and bandwidth at the same time.
> 
> http://www.dslreports.com/speedtest/319616
> 
> On Sat, Apr 18, 2015 at 5:57 PM, Rich Brown <richb.hanover at gmail.com> wrote:
> > Folks,
> >
> > I am delighted to pass along the news that Justin has added latency measurements into the Speed Test at DSLReports.com.
> >
> > Go to: https://www.dslreports.com/speedtest and click the button for your Internet link. This controls the number of simultaneous connections that get established between your browser and the speedtest server. After you run the test, click the green "Results + Share" button to see detailed info. For the moment, you need to be logged in to see the latency results. There's a "register" link on each page.
> >
> > The speed test measures latency using websocket pings: Justin says that a zero-latency link can give 1000 Hz - faster than a full HTTP ping. I just ran a test and got 48 msec latency from DSLReports, while ping gstatic.com gave 38-40 msec, so they're pretty fast.
> >
> > You can leave feedback on this page - http://www.dslreports.com/forum/r29910594-FYI-for-general-feedback-on-the-new-speedtest - or wait 'til Justin creates a new Bufferbloat topic on the forums.
> >
> > Enjoy!
> >
> > Rich
> > _______________________________________________
> > 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
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150419/cfa52661/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-04-19 at 3.08.56 pm.png
Type: image/png
Size: 14545 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150419/cfa52661/attachment-0002.png>