From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D331221F3B7 for ; Thu, 23 Apr 2015 21:17:20 -0700 (PDT) Received: by obfe9 with SMTP id e9so29341282obf.1 for ; Thu, 23 Apr 2015 21:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ML3q4EX/4MI/eqiqXS20+XNDCcwoVx+Je861wyGoOfQ=; b=fBWqB4aYpAd27U2eQSdqexK369W5M7U2Z98FAPjCIiUGP2wnMn0CBLHiItGcdpyJPq 58P6S4/7dvUzmHgmbedS6LkPyFqpJQa6XTmiI/g+PTtv9Elk7yOm2s7zeK+VolWrfNZ4 p+uQT2zZtEMjLDjX3wiTUDDiYS45zMHdbehDHvYJsWlPTga8Y6oR1Ac10dEV6FOAUCzt i4fixoRkAUlOMPV3jpmUC5FDacPZTRU3/9vv8xKwnDZYeFWSWOQmwStN/vlyYp+H3kXr jsoYbQzp0YPr5hHc9nEuaPouS4ZyNuYra1p0JjmIa/VCwhdK3jtoiKZPkj8JdsNcjCi1 m1Gw== MIME-Version: 1.0 X-Received: by 10.182.29.101 with SMTP id j5mr470889obh.0.1429849039645; Thu, 23 Apr 2015 21:17:19 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Thu, 23 Apr 2015 21:17:19 -0700 (PDT) In-Reply-To: References: <87wq18jmak.fsf@toke.dk> <87oamkjfhf.fsf@toke.dk> <87k2x8jcnw.fsf@toke.dk> <0D391BB1-9CA5-4DAF-8FD6-6628AB09C1C5@gmail.com> Date: Thu, 23 Apr 2015 21:17:19 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=UTF-8 Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 04:17:49 -0000 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.