On Tue, Apr 21, 2015 at 3:13 PM, jb <justin@dslr.net> wrote:

> Today I've switched it back to large receive window max.
>
> The customer base is everything from GPRS to gigabit. But I know from
> experience that if a test doesn't flatten someones gigabit connection they
> will immediately assume "oh congested servers, insufficient capacity" and
> the early adopters of fiber to the home and faster cable products are the
> most visible in tech forums and so on.
>
> It would be interesting to set one or a few servers with a small receive
> window, take them from the pool, and allow an option to select those,
> otherwise they would not participate in any default run. Then as you point
> out, the test can suggest trying those as an option for results with
> chaotic upload speeds and probable bloat. The person would notice the
> beauty of the more intimate connection between their kernel and a server,
> and work harder to eliminate the problematic equipment. Or. They'd stop
> telling me the test was bugged.
>

Well, the sawtooth pattern that's the classic sign of bufferbloat should be
readily detectable, especially if the pings during the test climb in a
similar fashion.  And from the two sets of numbers, it should be possible
to put a guess on how overbuffered the uplink is.  Then when the test
completes, an analysis that flags to the user that they have a bufferbloat
issue might continue to shed light on this.

Attached is results from my location which shows a couple hundred ms of
bloat.  While my results didn't have congestion collapse, they do clearly
have a bunch of bloat.  That amount of bloat should be easy to spot in an
analysis of the results, and a recommendation to the user that they may
want to look into fixing that if they use their link at the limit with VOIP
or gaming.

I just wish we had a really good un-bloated retail option to recommend.

-Aaron