From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BA738200830 for ; Sat, 7 Apr 2012 08:16:14 -0700 (PDT) Received: from pannekake.samfundet.no ([2001:700:300:1800::dddd] ident=unknown) by cassarossa.samfundet.no with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SGXMv-0002tN-1X; Sat, 07 Apr 2012 17:16:02 +0200 Received: from sesse by pannekake.samfundet.no with local (Exim 4.72) (envelope-from ) id 1SGXMu-0006T5-O3; Sat, 07 Apr 2012 17:16:00 +0200 Date: Sat, 7 Apr 2012 17:16:00 +0200 From: "Steinar H. Gunderson" To: Neil Davies Message-ID: <20120407151600.GA21452@uio.no> References: <20120406213725.GA12641@uio.no> <8C78AC1F-7305-4623-ADE6-1535CAA1FCBF@pnsol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8C78AC1F-7305-4623-ADE6-1535CAA1FCBF@pnsol.com> X-Operating-System: Linux 3.3.0 on a x86_64 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Best practices for paced TCP on Linux? 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: Sat, 07 Apr 2012 15:16:15 -0000 On Sat, Apr 07, 2012 at 04:08:20PM +0100, Neil Davies wrote: > That is the general idea - the issue is that the dynamic arrival rate as > "round trip window size" double just dramatically exceeds the available > buffering at some intermediate point - it is self inflicted (intra stream) > congestion with the effect of dramatically increasing the quality > attenuation (delay and loss) for streams flowing through that point. We've been tuning our stream to have more consistent frame sizes (adjusting the VBV settings); that seems to have alleviated the problems somewhat. > The packet train may also be an issue, especially if there is h/w assist > for TCP (which might well be the case here, as the interface was a 10G > one, comments Steinar?) - we have observed an interesting phenomena in > access networks where packet trains arrive (8+ packets back to pack at 10G) > for service down a low speed (2M) link - this leads to the effective > transport delay being highly non-stationary - with all that implies for the > other flows on that link. The card is a standard Intel 10GigE card, and we've turned off segmentation offload to avoid this precise issue. I've also tried hacking VLC to pace out the packets a bit more, but it didn't really seem to give the effect I had hoped, especially as things sometimes would glitch even without any packets actually being lost (which would contradict my “10GigE is too bursty” guess). The VBV tuning was a lot more efficient. /* Steinar */ -- Homepage: http://www.sesse.net/