From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 49C6321F249 for ; Mon, 4 May 2015 10:39:31 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t44HdMxS031524; Mon, 4 May 2015 10:39:22 -0700 Date: Mon, 4 May 2015 10:39:22 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Neil Davies In-Reply-To: Message-ID: References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> <2F4DCB53-1E46-4829-B2F8-F8131664D1FF@pnsol.com> <0F8CB21C-792F-4F95-BC49-BED3DF0A2100@unimore.it> <5D20E7F1-37D0-4CD3-8793-C29149695C97@pnsol.com> <48540B54-B7B0-428C-BA71-0BA5E40C6FB6@gmail.com> <5716B8D7-E2E7-4267-B8F1-9385329222B2@pnsol.com> <6DD94D01-DA3E-4099-A8CA-99A8C06567BC@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1615603218-1430761162=:2656" Cc: Jonathan Morton , bloat Subject: Re: [Bloat] Detecting bufferbloat from outside a node 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: Mon, 04 May 2015 17:40:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1615603218-1430761162=:2656 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 4 May 2015, Neil Davies wrote: > Jonathan > > We see the problem as the difference between averages and instantaneous. > > Network media is never “average” used - it is either “in-use” or “idle” - what > we were seeing (and it was not an ISP but the core of a public service network > here in the UK) was that delay can be “high” even when the loading is “low” > (in the particular 5minute period the actual offered traffic was <0.01% of the > capacity) - it was that the path under examination happened to be the > constraining factor for a bulk transfer - the induced delay was high enough to > place at risk other real-time applications (as defined by the public service > network’s users). If you are doing a single bulk data transfer through a link and are at a small percentage of the capacity but yet experiencing long delays, then something is wrong. either you have a small window size so that you aren't actually using the full capacity of the link, you are in the ramp-up time, or you have something dropping packets preventing you from getting up to full speed. But all of this should be affecting the sending machine and the speed that it is generating packets. the device should not be buffering anything noticable if it's at such a small percentage of utilization. check to see if there is QoS configuration on the system that may be slowing down this traffic (and therefor causing it to queue up) David Lang --680960-1615603218-1430761162=:2656--