Date: Tue, 31 May 2005 10:24:14 -0400 From: David Gilbert <dgilbert@dclg.ca> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-performance@FreeBSD.org, =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= <tuliogs@pgt.mpt.gov.br> Subject: Re: rmt as a bottleneck - Was: Weird behaviour of AIT-3 and (g)tar Message-ID: <17052.29582.462629.587978@canoe.dclg.ca> In-Reply-To: <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> <20050531130852.U1452@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Bruce" == Bruce Evans <bde@zeta.org.au> writes: >> 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; Bruce> ISTR that remote tars have a delay of 10 msec or so for each Bruce> block because the protocol needs to talk after each block (it Bruce> doesn't stream) and there is a TCP startup delay of this Bruce> amount. I have often considered the problem of remote tape devices. By way of introduction: I've done a lot of tape handling on UNIX and other systems for complex block formats. The UN*X tape model is rather simplistic. The primary problem with rmt (and UN*X tape in general) is that it cannot stream. If I signal "EOT" (end-of-tape) to tar, tar blithly assumes I meant the block you just wrote caused an EOT. Some tape hardware approximates streaming by estimating EOT ahead of time --- it certainly performs better, but it's not a great solution. Some tape programs on UN*X attempt to buffer heavily in RAM (team, etc)... but to overcome this shortcoming in the multi-tape case, they all need multi-volume smarts. Pretty much a mess. So... yes... there's a chatter for every block because the protocol needs to return the status of every block. I keep threatening to write the difinitive tape suite for FreeBSD ... but something more important always comes along. Problem is, everything needs rejiging ... tar, dump, tape drivers, rmt, etc. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17052.29582.462629.587978>