From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 20CC221F462 for ; Sun, 19 Apr 2015 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Sender: toke@toke.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1429465515; bh=wSJrSEZ1Q+laL4i/MnUnd6O1LbE0An7JCYrI+Plburw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=PYv9BmQhUk8uS4NH4wr2hYl+Di/OzBZ73GVOJL97AqLb3Sw0vxSRHlSRkcM85xVdj BalFZACN52qOfN6kAJZu6E/SZsTpanSRSrEj9z2SW2Ti2JGPZqXCnV8lRmogprZqUO uc0n3CU6/kD27WgKO9VcfpnIAMmPsistaATjkQ9w= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 536E3325EB9; Sun, 19 Apr 2015 19:45:14 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Mikael Abrahamsson References: <87wq18jmak.fsf@toke.dk> <87oamkjfhf.fsf@toke.dk> <87k2x8jcnw.fsf@toke.dk> Date: Sun, 19 Apr 2015 19:45:14 +0200 In-Reply-To: (Mikael Abrahamsson's message of "Sun, 19 Apr 2015 19:15:52 +0200 (CEST)") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fv7wj9lh.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Sun, 19 Apr 2015 17:45:51 -0000 Mikael Abrahamsson writes: > On Sun, 19 Apr 2015, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> The upload latency figures are definitely iffy, but the download ones >> seem to match roughly what I've measured myself on this link. > > Also, I don't trust parallel latency measures done by for instance > ICMP ping. Yes, they indicate something, but what? Why not? They can be a quite useful measure of how competing traffic performs when bulk flows congest the link. Which for many applications is more important then the latency experienced by the bulk flow itself... I do agree, though, that other types of measurements are also needed. Ideally we should have good latency characteristics for *both* competing traffic and the bulk flows themselves. -Toke