From owner-freebsd-performance@FreeBSD.ORG Tue May 31 03:18:11 2005 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62AC816A41C for ; Tue, 31 May 2005 03:18:11 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB27743D1D for ; Tue, 31 May 2005 03:18:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V3I9rI019432; Tue, 31 May 2005 13:18:09 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4V3I5MC030969; Tue, 31 May 2005 13:18:08 +1000 Date: Tue, 31 May 2005 13:18:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= In-Reply-To: <429B38C7.5040405@pgt.mpt.gov.br> Message-ID: <20050531130852.U1452@epsplex.bde.org> References: <428CF20F.50607@pgt.mpt.gov.br> <428D0D79.7010506@rcn.com> <428DFF35.1000409@pgt.mpt.gov.br> <429B38C7.5040405@pgt.mpt.gov.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@FreeBSD.org Subject: Re: rmt as a bottleneck - Was: Weird behaviour of AIT-3 and (g)tar X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 03:18:11 -0000 > Observe that I bypassed rmt; that bumped the transfer rate to 10.976.153,96 > Bytes/s, almost 30x faster. Should this really happen? (And yes, I read > rmt(8), but found nothing about this. :( ). > Thanks for your help; ISTR that remote tars have a delay of 10 msec or so for each block because the protocol needs to talk after each block (it doesn't stream) and there is a TCP startup delay of this amount. Bruce