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

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

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

On Mon, Mar 30, 2015 at 9:06 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

>
> > On 29 Mar, 2015, at 20:36, Pedro Tumusok <pedro.tumusok@gmail.com>
> wrote:
> >
> > Dslreports got a new speedtester up, anybody know Justin or some of the
> other people over there?
> >
> > http://www.dslreports.com/speedtest
> >
> > Maybe somebody on here could even lend a hand in getting them to
> implement features like ping under load etc.
>
> I gave that test a quick try.  It measured my download speed well enough,
> but the upload…
>
> Let’s just say it effectively measured the speed to my local webcache, not
> to the server itself.
>
>
Hi Jonathan,

I forwarded your observation to the Justin over at dslreports and I got the
following answer. I a bit in the middle here, but I'll see if I can get him
to join the mailing list, he seemed interested in bufferbloat at least.
Also would you mind doing another test and share the link for result, so he
can check closer?

""Let’s just say it effectively measured the speed to my local webcache,
not to the server itself."

If he runs an outbound squid, as the upload speed is measured continuously,
it will measure the speed to the squid, although why would configure it to
cache POSTs when the URL is unique and includes all the no-cache headers?
it doesn't make them any faster we still have to wait for the result.. I
believe his situation to be rather unique. 190,000 tests nobody else has
had that case.

Either way if he re-runs and sends me a link, I can look at the log and
work out how to"patch" the upload speed at the end to the right number
because it waits for the real reply from the server, with the amount
uploaded, and no web cache can fake that.

on the other things, yes I'd like to hear about buffer bloat ideas.
The simultaneous up+down mode would also be interesting.

Since I control the servers and don't use a CDN, I'm thinking of running
ng-capture constantly, then inspecting the tcptraces in real time. If there
is stuff that can drop out of that that is revealing it can be rolled into
the results.. Even without any buffer bloat issues, being able to see
packet loss directly would be a win for people with bad lines. It would
also pickup those TCP disasters between client and server when they can't
agree on something or things are fragmented etc etc."



What do you guys think about his packet capture ideas? There are a lot of
users over on dslreports, so if they put up a speedtest with bufferbloat
"detectors" it could be another thing to get the snowball to roll.

I also removed cerowrt dev list, do not think we need to cross post to that
one.
-- 
Best regards / Mvh
Jan Pedro Tumusok

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