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

[Dave Taht <dave.taht@gmail.com>]

OK, I have had a little more fun fooling with this.

A huge problem all speedtest-like results have in general is that the
test does not run long enough. About 20 seconds is needed for either
up or down to reach maximum bloat, and many networks have been
"optimized" to look good on the "normal" speedtests which are shorter
than that. It appears this test only runs for about 15 seconds, and
you can clearly see from this result

http://www.dslreports.com/speedtest/353034

that we have clogged up the link in one direction which has not
cleared in time for the next test to start.

While consumer patience is limited, I would

A) recommend increasing the duration of the upload and download tests
by at least 5, maybe 10 seconds. I note that this change, made
universally across more tests, would also make for better tests.
Everyone's impression of how their connection is working is shaped by
speedtest not running long enough.

B) However, the reason why I designed the 60 second long rrul
(up+down+ping) test was that it detects maximum bloat in minimal time,
usually peaking in about 20 seconds on every access technology we have
at reasonable RTTs. I would rather like a test like that in this
dslreports suite.

I keep hammering away at the idea that bloat happens in both
directions - which is most easily created by bittorrent-like behavior
- but just as easily created by someone, or their family, or their
officemates doing an upload and download on the same link. Fixing the
CMTSes and head-ends also needs to happen. No matter how much we can
improve matters with an inbound shaper on cpe/home routers, doing it
right on the head-ends is MUCH nicer, lower jitter, etc.

C) waiting for the bloat to clear would be a good idea before starting
the next test.... and showing "waiting for the bloat to clear"  as
part of the result would be good also.