I managed to remove a "t" on the end there....

Pedro

---------- Forwarded message ----------
From: Pedro Tumusok <pedro.tumusok@gmail.com>
Date: Tue, Apr 7, 2015 at 7:15 PM
Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?)
To: jb <justinbeech@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.ne>

On Sat, Apr 4, 2015 at 2:03 PM, jb <justinbeech@gmail.com> wrote:

Hi,
Thanks for the indirect invitation to the list I'm looking forward to following it and learning stuff.

If I had one question now, it would be this. Should I put effort into measuring ongoing RTT during the "full" download and upload phases, or should I put effort into running packet captures at some of the test locations, storing them, and processing them later, with the idea that this will reveal in conjunction with speed test result files, actual TCP RTT times during times when a residential connection is full. Even packet capturing at one location would capture a lot of individuals because of the many to one setup of the server-client.

From earlier discussions on here, I think the RTT during "full" download and upload phases. is what most people on here want to see. Since it will tell us how any latency sensitive service will be affected by the buffers in the equipment when the connection is under heavy load. In tune with your "We are not interested in making your ISP look good", on here we are interested in making your device vendor look "bad". So that they actually can fix this, because its about them fixing their hardware, the solutions are there, they just need to do it.

Having full captures is icing on the cake, but to just show the induced delay by the equipment is 90% of the way. But as all projects, the last 10% is the toughest part.

Personally I think that if your speed test shows people the "true" experience, ie bad, they can expect from their setup, it will be immensely valuable for you and the bufferbloat project. And of course you will be copied on it, as before, by other speed test sites/tools.

Bad analogies wise, having the best speed is like inserting a Porsche high performance car engine into a VW Beetle. You have the potential for going very fast, but it will be a very scary and uncomfortable ride, especially if you compare it to using that engine in a "real" Porsche.

Anything that is produced from this project might have to be crunched by an interested person other than me, because of the number of different devices and browsers and undocumented limits I've still got my hands full making sure the maximum number of people get a "competitive" speed reading. Making sure the majority drive their connection to capacity is probably a necessary condition for accurate conclusions on anything else anyway.

I assume that a lot of the people on here can use it for their daily work and I think there are some academics/scientists on here, that would love to have a copy of the date for research.

Pedro

On Thu, Apr 2, 2015 at 4:21 AM, Pedro Tumusok <pedro.tumusok@gmail.com> wrote:
Justin,

If you got any questions, don't feel shy :)
If there is any testing I can help with etc, let me know.

Pedro

On Tue, Mar 31, 2015 at 7:07 AM, Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:

On Mon, 30 Mar 2015 18:05:19 +0200 Pedro Tumusok <pedro.tumusok@gmail.com> wrote:

[...]
> That is feature creep, we originally discussed having continuous ping
> measurement under load.
> New ideas not so welcome ;)

I agree, we just want Justin (http://www.dslreports.com/speedtest) to
also measure and report on ping/latency under load.

After we have this basic step, we can refine it further, e.g. with
Jonathan HZ measurement.

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer

--
Best regards / Mvh
Jan Pedro Tumusok

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Best regards / Mvh
Jan Pedro Tumusok