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. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
