From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t5424.austin.hp.com (g1t5424.austin.hp.com [15.216.225.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6892F21F3DD for ; Fri, 24 Apr 2015 09:13:53 -0700 (PDT) Received: from g2t2360.austin.hp.com (g2t2360.austin.hp.com [16.197.8.247]) by g1t5424.austin.hp.com (Postfix) with ESMTP id BBB81104 for ; Fri, 24 Apr 2015 16:13:52 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g2t2360.austin.hp.com (Postfix) with ESMTP id 8D186917 for ; Fri, 24 Apr 2015 16:13:52 +0000 (UTC) Message-ID: <553A6BC0.2080600@hp.com> Date: Fri, 24 Apr 2015 09:13:52 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <87oamkjfhf.fsf@toke.dk> <87k2x8jcnw.fsf@toke.dk> <0D391BB1-9CA5-4DAF-8FD6-6628AB09C1C5@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:14:26 -0000 On 04/23/2015 09:17 PM, Dave Taht wrote: > 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. Perhaps then that phase of the test shouldn't be considered complete? In a netperf TCP_STREAM or TCP_MAERTS test, the test isn't over until there is an indication the last byte has arrived. As such, what one might request to be a 30 second test can end-up with say a 34 second elapsed time. That is I suppose along the lines of your proposal C. > 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. rick jones