[Bloat] Fwd: Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?)

[Pedro Tumusok <pedro.tumusok@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]

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




-- 
Best regards / Mvh
Jan Pedro Tumusok

[-- Attachment #2: Type: text/html, Size: 7121 bytes --]