Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site onfcanim.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: Tar(1) portability???
Message-ID: <14776@onfcanim.UUCP>
Date: Thu, 16-Jan-86 12:45:49 EST
Article-I.D.: onfcanim.14776
Posted: Thu Jan 16 12:45:49 1986
Date-Received: Fri, 17-Jan-86 03:19:28 EST
References: <535@smeagol.UUCP> <4500001@occrsh.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: ONF, Montreal
Lines: 29

[People have been discussing tape controller limitations on the 3B series
of computers]

With the exception of a few recent products, DEC controllers (disk and tape)
have never buffered the data they were handling, except for a small silo
in some cases to smooth out data flow.  Thus, they have always been able
to transfer as many bytes as you could ask for, which was either 2^16 bytes
or 2^16 (16-bit) words, depending on the controller.

Thus, anyone else who builds a controller that emulates DEC hardware is
also going to support large transfers.

On a workstation with 1/4 inch cartridge tape drive (SGI IRIS), the "standard"
block sizes for tar and cpio are 200Kb and 250Kb respectively, to make the
best use of the drive - it has to back up and take a flying start for
every block read.

And from the standpoint of tape use, even a block size of 20 isn't that
high; it results in wasting 10% of the tape in interrecord gaps at 1600BPI,
and much more at 6250.

Now, for a question:  Why would anyone in their right mind design a tape
controller that could only handle 5Kb records?  Surely the data doesn't
have to be buffered?  Only the very fastest tape drives (6250 BPI at
125 or 200 IPS) handle data at anything close to the rates that the
system bus *must* be able to handle in order to handle any kind of decent
disk.

	Dave Martindale