sysmark@physics.utoronto.ca (Mark Bartelt) (02/09/91)
I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded
to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's
nice to finally be able to read/write arbitrary-length tape records!
However, I've found that there's a record size limit of 240k bytes. Any
attempts to write records longer than that return EINVAL. Is this just a
misfeature of the IRIX tape driver, or is it a characteristic of exabyte
drives, or a limit (general, or SGI's) on the size of SCSI transfers, or
what? And, whichever, why was 240k chosen?
For that matter, should I even care? Back in ancient times, when all we
had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing
data in blocks as large as possible, to minimize the amount of tape that
was wasted in inter-record gaps. How, exactly, do exabytes separate the
physical records? And how much tape does that information use, compared
with the length of an N-byte record?
Mark Bartelt 416/978-5619
Canadian Institute for sysmark@cita.toronto.edu
Theoretical Astrophysics sysmark@cita.utoronto.canorsk@sequent.UUCP (Doug Thompson) (02/09/91)
In article <1991Feb8.154343.11054@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: >I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded >to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's >nice to finally be able to read/write arbitrary-length tape records! > >However, I've found that there's a record size limit of 240k bytes. Any >attempts to write records longer than that return EINVAL. Is this just a >misfeature of the IRIX tape driver, or is it a characteristic of exabyte >drives, or a limit (general, or SGI's) on the size of SCSI transfers, or >what? And, whichever, why was 240k chosen? Its a limit of the drive itself. It has a maximum buffer (for data) of 240kb. Cost probably was the reason. The 8500 exabyte drive has a bigger buffer. > >For that matter, should I even care? Back in ancient times, when all we >had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing >data in blocks as large as possible, to minimize the amount of tape that >was wasted in inter-record gaps. How, exactly, do exabytes separate the >physical records? And how much tape does that information use, compared Physical records on 1kb records grouped 8 records per helical track, 8kb per track. If data is a multiple of 8K and the device keeps streaming no interrecord gap is present. If the device enters a stop/start mode, then one will get gaps. >with the length of an N-byte record? -- Douglas Thompson UUCP: ..{tektronix,ogicse,uunet}!sequent!norsk Internet: norsk@sequent.com "The scientist builds to learn; the engineer learns in order to build." Fred Brooks
ralph@uhheph.phys.hawaii.edu (Ralph Becker-Szendy) (02/09/91)
In article <1991Feb8.154343.11054@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: >I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded >to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's >nice to finally be able to read/write arbitrary-length tape records! > >However, I've found that there's a record size limit of 240k bytes. Any >attempts to write records longer than that return EINVAL. Is this just a >misfeature of the IRIX tape driver, or is it a characteristic of exabyte >drives, or a limit (general, or SGI's) on the size of SCSI transfers, or >what? And, whichever, why was 240k chosen? > >For that matter, should I even care? Back in ancient times, when all we >had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing >data in blocks as large as possible, to minimize the amount of tape that >was wasted in inter-record gaps. How, exactly, do exabytes separate the >physical records? And how much tape does that information use, compared >with the length of an N-byte record? > >Mark Bartelt 416/978-5619 >Canadian Institute for sysmark@cita.toronto.edu >Theoretical Astrophysics sysmark@cita.utoronto.ca First of all, the drive writes 8kB "blocks". The term to use is probably "diagonal strip of data", since each pass of the helical scan head over the tape makes a diagonal strip. As far as I understand the little bit of documentation Summus gave us with our drives (which I can't find anywhere right now) each physical stripe contains an 8kB block of user data, and an extra ~2kB of ECC data, but don't quote me on that. If you write records less then 8Kb (or less than a multiple of 8kB) the rest of the block will be wasted. Therefore writing 1kB blocks is a real dumb idea. If you stick to records of 8kB or multiples (maybe for safety reasons shave a few bytes off that) the space should be used maximally efficient. There is no inter-record gap, since the position of the next strip is fixed by the relative motion of the head and the tape. Second, the drive has a 256kB buffer. That probably causes the 240kB record size limit: The drive wants to have the WHOLE record in the buffer before it starts writing. Why would anyone want to write records that large anyhow? Tape space usage is already maximized by having 8kB (or multiple) records. The performance gain (CPU overhead for each record) should stop being significant long before you reach records that long, shouldn't it ? -- Ralph Becker-Szendy UHHEPG=24742::RALPH (HEPNet,SPAN) University of Hawaii RALPH@UHHEPG.PHYS.HAWAII.EDU High Energy Physics Group RALPH@UHHEPG.BITNET Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 (808)956-2931
olson@newmedia.esd.sgi.com (Dave Olson) (02/09/91)
In <1991Feb8.152435.10875@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: | I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded | to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's | nice to finally be able to read/write arbitrary-length tape records! It was available all along; you just needed to run cd /dev; MAKEDEV tps to create them... | However, I've found that there's a record size limit of 240k bytes. Any | attempts to write records longer than that return EINVAL. Is this just a | misfeature of the IRIX tape driver, or is it a characteristic of exabyte | drives, or a limit (general, or SGI's) on the size of SCSI transfers, or | what? And, whichever, why was 240k chosen? 240K is the amount of usable RAM on the drive for buffering data, and this limits the maximum size of a single 'block', due to the way the drive firmware is written. The actual blocking on the tape is 1K in any case, so you gain little or nothing in performance by increasing the size past about 128K. | For that matter, should I even care? Back in ancient times, when all we | had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing | data in blocks as large as possible, to minimize the amount of tape that | was wasted in inter-record gaps. How, exactly, do exabytes separate the | physical records? And how much tape does that information use, compared | with the length of an N-byte record? The only thing you gains is if it makes your software easier to write. The 'block size' is written as part of the header info. Larger block sizes gain you no capacity or performance. You DO want to make sure the block sizes is a multiple of 1024 for maximum capacity, otherwise the size % 1024 is wasted in the last 'real' block of each write; a block size of 512 wastes half the tape.
jeremy@cs.adelaide.edu.au (Jeremy Webber) (02/10/91)
Hi all, FYI, I did some performance tests on an Exabyte connected to a Sun 4/280 some years ago, and found that transfer rate was maximized for transfers of 64K. That is, transfers below that block size were substantially slower, and transfers above that block size showed no noticable gain. Very small transfers also seemed to use more *tape* than larger transfers. I'm not sure why. 1K blocks got less than half the storage on the tape that 64K blocks did. All block sizes were multiples of 1K. -jeremy -- -- Jeremy Webber ACSnet: jeremy@chook.ua.oz Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au 3 Milner St, Hindmarsh, SA 5007, Voicenet: +61 8 346 4534 Australia Papernet: +61 8 346 4537 (FAX)
bobw@cd_player.wv.tek.com (Bob Wood) (02/12/91)
In article <1991Feb8.154740.11155@helios.physics.utoronto.ca>, sysmark@physics.utoronto.ca (Mark Bartelt) writes: > Path: orca.wv.tek.com!zephyr.ens.tek.com!uunet!bonnie.concordia.ca!news-server .csri.toronto.edu!helios.physics.utoronto.ca!physics.utoronto.ca!sysmark > From: sysmark@physics.utoronto.ca (Mark Bartelt) > Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi > Subject: exabyte record size limit > Message-ID: <1991Feb8.154740.11155@helios.physics.utoronto.ca> > Date: 8 Feb 91 20:47:40 GMT > Organization: University of Toronto Physics/Astronomy/CITA > Lines: 20 > Xref: orca.wv.tek.com comp.periphs:3751 comp.sys.sgi:8297 comp.periphs.scsi:1862 > > I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded > to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's > nice to finally be able to read/write arbitrary-length tape records! > > However, I've found that there's a record size limit of 240k bytes. Any > attempts to write records longer than that return EINVAL. Is this just a > misfeature of the IRIX tape driver, or is it a characteristic of exabyte > drives, or a limit (general, or SGI's) on the size of SCSI transfers, or > what? And, whichever, why was 240k chosen? This is the limit specified in the Exabyte documentation. All SCSI tape drives I have seen limit the maximum variable length record size to what can be held in the drive controllers data buffer. The drive needs to be able to retry reads and writes without involving the SCSI bus and driver. I think most drives will read an entire record into local memory and check for correctness before starting the SCSI transfer. Thus the variable length record usually must fit in the on board buffer. The Exabyte has a 256k buffer. I don't know why they restrict read/write to 240k. Perhaps they use the other space for control information. I know why the above is true for a nine track drive. I am not so sure why the Exabyte must behave this way. It does not write true variable length records with a record gap between each one like a nine track. The Exabyte simulates variable length record operation on a fixed length record format. See comments below. > > For that matter, should I even care? Back in ancient times, when all we > had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing > data in blocks as large as possible, to minimize the amount of tape that > was wasted in inter-record gaps. How, exactly, do exabytes separate the > physical records? And how much tape does that information use, compared > with the length of an N-byte record? The record length does not effect tape capacity of the Exabyte in the same way as a nine track tape. The Exabyte always writes 1024 byte records on the tape. Additionally it always writes 8 of these records per scan(it is a helical scan device like a VCR). (The above applies to the 2.3 gig drive, the newer drive may have different numbers) If you write anyting that is not a multiple of 1024 bytes, you lose capacity. What you lose will be the part of the last 1024 byte physcial block that was needed to pad to a multiple os 1024. The drive will put the logical record length in a header so you don't see this padding from the host. You can also lose capacity if the host does not send data to the drive fast enough. The drive must always write a complete scan of 8 1k blocks. If it runs out of data part way through a scan, It will pad the rest of the scan. Again this is transparent to the host except as lost tape capacity. I am not sure how you minimize the padding of these 8k tracks. The drive has 256k of buffering. It has some intellegence about how much data must be in the buffer before it starts or stops the drive. Mostly I don't worry about this part very much. What is really important is to use multiples of 1024 bytes. For example if you write 512 byte records, you lose 50% of the tape capacity! > > Mark Bartelt 416/978-5619 > Canadian Institute for sysmark@cita.toronto.edu > Theoretical Astrophysics sysmark@cita.utoronto.ca
sgf@cs.brown.edu (Sam Fulcomer) (02/12/91)
In article <52691@sequent.UUCP> norsk@eng3.UUCP (Doug Thompson) writes: >In article <1991Feb8.154343.11054@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: >>I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded >>to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's >>nice to finally be able to read/write arbitrary-length tape records! Well, some people have it mostly right. The 8200 has a 256k data buffer. The maximum logical block length for fixed or variable block modes is 240k. the physical block length is 1024 bytes. The data buffer circuitry adds block address and tag information in the data buffer, hence the 240k limit. The 8200 format writes 8 physical blocks of data (1024 bytes each, with 400 bytes ECC and 16 bytes address) during each physical write operation. The result is one diagonal stripe or "track" on the tape. (Note that this is ALWAYS the case.) so there isn't really an arbitrary-length record on the tape in the sense that there is on the typical 1/2" (capacity doesn't increase with increased block size past 1k in 1k multiples , and there's no "record mark" or inter-record gap on the tape, since gaps can occur). The most inefficient use possible for the 8200 is with a block length of 1 and unbuffered write mode (when issuing a write operation in fixed block mode with a transfer size of only one block). This will yield a stripe consisting of 1 physical block containing user data (a 1024 byte physical block containing a 1-byte logical block followed by pad bytes) and 7 gap blocks. The next 8k stripe will consist of 8 more gap blocks, which serve as a marker for the firmware on a reposition for the correct location to continue writing. Thus, where you could have had 16k of data on the tape, you only have 1 byte. I assume that most sensible drivers use buffered mode writes, however. In buffered mode writes the data buffer fills up to a predetermined point before the drive actually writes the data to tape. The predetermined point is called the "write motion threshold" and defaults to 240k. At this point the write circuitry begins transferring data to the tape. I presume that the reason it defaults to 240k is to allow it to determine whether a block's worth of data has been transferred before writing. The most efficient use of the tape can be made by using a logical block size (with buffered and either fixed or variable mode) which is always some multiple of 1k and by keeping the buffer from emptying.
mcconnel@b11.ingr.com (Guy McConnell) (02/15/91)
In article <1991Feb8.152435.10875@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: >I have an exabyte drive (from Dilog) on a 4D25. When I recently upgraded >to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices: It's >nice to finally be able to read/write arbitrary-length tape records! > >However, I've found that there's a record size limit of 240k bytes. Any >attempts to write records longer than that return EINVAL. Is this just a >misfeature of the IRIX tape driver, or is it a characteristic of exabyte >drives, or a limit (general, or SGI's) on the size of SCSI transfers, or >what? And, whichever, why was 240k chosen? The maximum logical block size that the Exabyte supports is 240K. Why? I don't know. >For that matter, should I even care? Back in ancient times, when all we >had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing >data in blocks as large as possible, to minimize the amount of tape that >was wasted in inter-record gaps. How, exactly, do exabytes separate the >physical records? And how much tape does that information use, compared >with the length of an N-byte record? The Exabyte does not seperate physical records unless they are in different save-sets. At the end of a write operation the drive writes a "gap track" which consists of 8 "gap blocks", or one track (0.025mm wide) of non-data that is not accessible by the user. It uses this for orientation purposes on an append operation. If you tell it to, it then writes filemark(s) which *do* take up a bit of space. They are the equivalent of 2.2Mb long each. This sounds like a lot but during my capacity testing, I wrote 17 different data save-sets to a 112m tape with a filemark between each and two filemarks at the end. I still got 2.3Gb of data on the tape. Far more important is the use of a blocking factor that is an even multiple of 8192. Because of the way the drive writes data on the tape, if you use something other than a product of 8K, you lose capacity. Each helical track on the tape contains eight 1024 byte *physical* blocks of user data. The minimum writable unit for the drive is one track. Therefore, if you use a block size of, say, 10240, you'll get a logical block containing one track with 8K (8 1K blocks) of user data and one track containing 2K of user data and 6K of "gap blocks". Multiply this by the length of a whole tape and it becomes significant. Worse still, if you use a block size of 512 bytes, *each* physical block on the tape (1K each) will contain 512 bytes of user data and 512 bytes of "pad data" which will effectively cut the tape capaity in half. I use a block size of 32768 and it works fine. -- ============================================================================== Guy D. McConnell | | "All that is gold does not Intergraph Corp. Huntsville, AL. | Opinions | glitter, not all those who Mass Storage Peripheral Evaluation | herein | wander are lost, the old Tape Products | are mine | that is strong does not uunet!ingr!b11!mspe5!guy | alone. | wither, and deep roots are (205)730-6289 FAX (205)730-6011 | | not touched by the frost." ==============================================================================
olson@anchor.esd.sgi.com (Dave Olson) (02/15/91)
In <1991Feb14.223941.4318@b11.ingr.com> mcconnel@b11.ingr.com (Guy McConnell) writes: ... | Far more important is the use of | a blocking factor that is an even multiple of 8192. Because of the way the | drive writes data on the tape, if you use something other than a product of | 8K, you lose capacity. Each helical track on the tape contains eight 1024 | byte *physical* blocks of user data. The minimum writable unit for the drive | is one track. Therefore, if you use a block size of, say, 10240, you'll get | a logical block containing one track with 8K (8 1K blocks) of user data and | one track containing 2K of user data and 6K of "gap blocks". This is not correct, according to the tech people I have talked to at Exabyte, and the manual. The only time the padding to 8K occurs is when you can't keep enough data in the buffer. If the drive is writing, and there is not enough data to fill out a track (8K), then, and only then, will it pad the track out. A special case of this, is of course, the last write before a FM or rewind. If course, if your application is doing some kind of logging, and is doing intermittent writes of fairly small size, then it is probably a good idea to do your writes as a multiple of 8K, even if this means adding soe buffering to the app. Note that the multiple of 1K issue (padding to 1K at end of each logical block, if not a multiple) applies whether in fixed or variable block mode, and is independent of the 8K track padding. -- Dave Olson Life would be so much easier if we could just look at the source code.
sgf@cs.brown.edu (Sam Fulcomer) (02/15/91)
In article <1991Feb14.223941.4318@b11.ingr.com> mcconnel@b11.UUCP (Guy McConnell) writes: > > The Exabyte does not seperate physical records unless they are in different >save-sets. At the end of a write operation the drive writes a "gap track" This is true after a tape controller write operation, but not necessarily true after the driver-level write (ie, the scsi CDB and data transfer). If the drive is operating in buffered mode it will not write until the buffer content reaches the tape movement threshold (or until the electronics are taken out of write mode by some other operation) and will then continue to write as much data as it has in its buffer, which may contain many user-blocks (ie, the controller write operation continues until the buffer is empty, without gap blocks or tracks, regardless of the characteristics of the user-block). >end. I still got 2.3Gb of data on the tape. Far more important is the use of >a blocking factor that is an even multiple of 8192. Because of the way the >drive writes data on the tape, if you use something other than a product of >8K, you lose capacity. Each helical track on the tape contains eight 1024 >byte *physical* blocks of user data. The minimum writable unit for the drive >is one track. Therefore, if you use a block size of, say, 10240, you'll get >a logical block containing one track with 8K (8 1K blocks) of user data and >one track containing 2K of user data and 6K of "gap blocks". Multiply this See my comments above. This is not the documented operation of my 8200 units, and I haven't been surprised by empirical evidence. Buffered mode and 1k-multiple block size appear to be the only important parameters. Since an intelligently designed driver would default to buffered mode for any tape device that can handle it, most people would only need to worry about the 1k-multiple block size (eg, SGI and Sun users...). This whole thing is getting a bit tedious. If anyone has any contradicting comments let's continue via e-mail until a consensus can be posted.
mcconnel@b11.ingr.com (Guy McConnell) (02/19/91)
In article <64513@brunix.UUCP> sgf@cs.brown.edu (Sam Fulcomer) writes: [In regard to Exabyte record size limits] >Well, some people have it mostly right. The 8200 has a 256k data buffer. >The maximum logical block length for fixed or variable block modes is 240k. >the physical block length is 1024 bytes. The data buffer circuitry >adds block address and tag information in the data buffer, hence the 240k >limit. > >The 8200 format writes 8 physical blocks of data (1024 bytes each, with 400 >bytes ECC and 16 bytes address) during each physical write operation. Actually, there are 400 bytes of ECC, 14 bytes of address, and 2 bytes of CRC per 1K block. The drive writes more than the 8 1K blocks during each "physical write" in which a larger logical block size was specified. Perhaps you meant during each rotation of the head during a write. > >I assume that most sensible drivers use buffered mode writes, however. >In buffered mode writes the data buffer fills up to a predetermined >point before the drive actually writes the data to tape. The predetermined >point is called the "write motion threshold" and defaults to 240k. It is called the "motion threshold" because it is equally valid for reads and writes and it defaults to 80H or 128KBytes. It is Mode Selectable and the valid values are from 20H to D0H (32KBytes to 208KBytes). -- ============================================================================== Guy D. McConnell | | "All that is gold does not Intergraph Corp. Huntsville, AL. | Opinions | glitter, not all those who Mass Storage Peripheral Evaluation | herein | wander are lost, the old Tape Products | are mine | that is strong does not uunet!ingr!b11!mspe5!guy | alone. | wither, and deep roots are (205)730-6289 FAX (205)730-6011 | | not touched by the frost." ============================================================================== "))"
sgf@cs.brown.edu (Sam Fulcomer) (02/20/91)
In article <1991Feb18.175737.19866@b11.ingr.com> mcconnel@b11.UUCP (Guy McConnell) writes: >In article <64513@brunix.UUCP> sgf@cs.brown.edu (Sam Fulcomer) writes: >[In regard to Exabyte record size limits] > >> >>The 8200 format writes 8 physical blocks of data (1024 bytes each, with 400 >>bytes ECC and 16 bytes address) during each physical write operation. > > Actually, there are 400 bytes of ECC, 14 bytes of address, and >2 bytes of CRC per 1K block. The drive writes more than the 8 1K >blocks during each "physical write" in which a larger logical block >size was specified. Perhaps you meant during each rotation of the >head during a write. Ummm, doesn't the 16 bytes of address info include 2 bytes of CRC? I consider an physical write operation to contain of only one formatted track because a formatted track is the atomic unit of physical data on the tape, and because (through no coincidence) it is at this level that error detection (and write retry) is accomplished by the write driver circuitry via direct-read-after-write. >>point is called the "write motion threshold" and defaults to 240k. > It is called the "motion threshold" because it is equally valid >for reads and writes and it defaults to 80H or 128KBytes. It is >Mode Selectable and the valid values are from 20H to D0H (32KBytes >to 208KBytes). I happened to be speaking of the "Motion Threshold", as it is called, in the context of write operations (it's action is different in a read context), and, in the firmware I've got, it defaults to 240k in a valid range of 0x1-0xf7h kilobytes. I'm sorry; I'll never again post numbers without rev-levels. finis.
co@fy.chalmers.se (Christer Olsson) (02/23/91)
In article <1991Feb14.223941.4318@b11.ingr.com> mcconnel@b11.UUCP (Guy McConnell) writes: >In article <1991Feb8.152435.10875@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes: > We have a uVAX II/GPX with an IBIS 1.2 Gigabytes videodisc. The Imageprocessing system backups the disk into some hundreds of savesets (one saveset contains one picture and a desciptorfile.). Today, we use a TK50 tapedrive (95 meg) and a complete backup needs a half week continous running... Therefore, we have some plans to buy an Exabyte tapedrive and connect it to a SCSI-host on the machine. But, can an Exabyte handle so many savesets without loosing capacity? I think a complete backup generate more than 600-700 savesets. Is it possible for a slow uVAX II vith VMS 4.7 backup to feed an Exabyte with enough data without loosing space? I think an Exabyte needs at least 100K/byte per second under writing a saveset? (no saveset is smaller than 400K, some savesets is 300 Mbyte large)
olson@anchor.esd.sgi.com (Dave Olson) (02/23/91)
In <1991Feb22.165448.11408@fy.chalmers.se> co@fy.chalmers.se (Christer Olsson) writes: | We have a uVAX II/GPX with an IBIS 1.2 Gigabytes videodisc. The | Imageprocessing system backups the disk into some hundreds of savesets | (one saveset contains one picture and a desciptorfile.). | | But, can an Exabyte handle so many savesets without loosing capacity? | I think a complete backup generate more than 600-700 savesets. You lose aproximately 2 Mb per filemark with the (more common?) long FM's, and I assume your savesets are seperated by FM's. This means about 1/2 the tape would be used by FM's. Some drivers/manufactures default to short FM's, which use less tape, but which don't allow you to append at arbitrary points. It sounds like that would be fine for your use. (The SGI tape driver writes only long FM's, by the way). | Is it possible for a slow uVAX II vith VMS 4.7 backup to feed an | Exabyte with enough data without loosing space? I think an Exabyte | needs at least 100K/byte per second under writing a saveset? (no saveset is | smaller than 400K, some savesets is 300 Mbyte large) Can't help you with the uVAX, but to keep the Exabyte streaming continuously, you need to feed it data at about 240 Kbytes/sec. -- Dave Olson Life would be so much easier if we could just look at the source code.