melanie@director.beckman.uiuc.edu (Melanie Anderson) (05/15/91)
what is the 'recording density' of a TLZ04? and length? inquiring minds want
to know.
--
Melanie Anderson msa@uiuc.edu
Beckman Institute PHMETR::MELANIE
University of Illinois 217/244-1079
-----------------------------------------------------------------------------
Of all the things I've lost, I miss my mind the most.
-----------------------------------------------------------------------------sdj@rivar.reo.dec.com (simon jackson) (05/15/91)
Hi, from the little book you get with the TLZ04. Bit Density 114 Mbits/sq inch. I doesn't say how long the tape is though. Cheers Simon...
aej@manyjars.WPI.EDU (Allan E Johannesen) (05/15/91)
On 15 May 91 01:20:25 GMT, melanie@director.beckman.uiuc.edu (Melanie Anderson) said: melanie> Sender: usenet@ux1.cso.uiuc.edu (News) melanie> what is the 'recording density' of a TLZ04? and length? melanie> inquiring minds want to know. With a simple test program, I found I could write 107,528 10240 byte blocks to the dat before error. It would write 39,792 32768 byte blocks, if anyone cares (I have a different system which writes this different 'dump' blocksize). Anyway, using sd 12000 6520, I observed that the tape utilization is "safe". i.e. dump says "<some number> of 10240 byte blocks is <some percent> of the tape", and <some number> is well under <some percent> of 107,528 (of course, I imagine this number could change on different test runs even on the same tape). i.e. this is very conservative. I haven't used it on any filesystems which would test the boundary, so I haven't worked up a more accurate s/d setup; you can experiment until you find that the s/d formula yields a closer block-to-percent ratio.
dcb@dave.mis.semi.harris.com (Dave Brillhart) (05/15/91)
I'm looking at a TLZ04 drive. It says 60m in the tape. Assuming that means 60 meters (2363 inches) and it's 4mm wide (0.157 inches). That gives us 372 sq in of surface area. My book says it holds 1.2G... -- Dave
melanie@director.beckman.uiuc.edu (Melanie Anderson) (05/16/91)
aej@manyjars.WPI.EDU (Allan E Johannesen) writes: >On 15 May 91 01:20:25 GMT, >melanie@director.beckman.uiuc.edu (Melanie Anderson) said: >melanie> Sender: usenet@ux1.cso.uiuc.edu (News) >melanie> what is the 'recording density' of a TLZ04? and length? >melanie> inquiring minds want to know. >With a simple test program, I found I could write 107,528 10240 byte >blocks to the dat before error. It would write 39,792 32768 byte >blocks, if anyone cares (I have a different system which writes this >different 'dump' blocksize). thanks for the info, but that's not exactly what i asked. i already know i can get about a gig or so on a tape. i meant 'record density' as in 'bit density' as in 1600bpi or 6250bpi or 2**164b/sqmm or whatever. you can take blocksize * total blocks written to end of tape / tape length and get a rough approximation, but that ignores the inter-block gap and also assumes you know the length (which i can't find anywhere on the packaging of the maxell tapes i buy, i mean, you get all sorts of bizzare tape info on commercial audio cassettes like length, dynamic range, record speed, shell color availability, but all i get on my dat tapes is "Adoption of newly developed superfine ceramic armor metal-particle magnetic material achieves superb durability and high output. Reproduces excellent high-fidelity digital sound even after repeated use." well i would certainly *hope* so!) this is all just for my own personal edification -- diatribes on how DAT data is recorded would be most welcome. the TLZ manual is not exactly informative. -- Melanie Anderson msa@uiuc.edu Beckman Institute PHMETR::MELANIE University of Illinois 217/244-1079 ----------------------------------------------------------------------------- Of all the things I've lost, I miss my mind the most. -----------------------------------------------------------------------------
jch@hollie.rdg.dec.com (John Haxby) (05/16/91)
"mt status" suggests it's 61000 bpi. The 60m appears to correspond to 60 minutes for audio. 61000bpi corresponds to 1466 recording feet, which is not unreasonable since it records by helical scan. Personally, I just let dump get on with it, it stops when it reaches EOT, but I haven't managed to fill a tape yet. -- John Haxby, Definitively Wrong. Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch> ---------------------------------------------------------------- The opinions expressed herein are my own, not my employers.
olson@anchor.esd.sgi.com (Dave Olson) (05/17/91)
In <1991May15.183245.10467@ux1.cso.uiuc.edu> melanie@director.beckman.uiuc.edu (Melanie Anderson) writes: | >melanie> what is the 'recording density' of a TLZ04? and length? | >melanie> inquiring minds want to know. | | thanks for the info, but that's not exactly what i asked. i already | know i can get about a gig or so on a tape. i meant 'record density' as | in 'bit density' as in 1600bpi or 6250bpi or 2**164b/sqmm or whatever. | you can take blocksize * total blocks written to end of tape / tape | length and get a rough approximation, but that ignores the inter-block | gap and also assumes you know the length (which i can't find anywhere | on the packaging of the maxell tapes i buy, i mean, you get all sorts | of bizzare tape info on commercial audio cassettes like length, dynamic | range, record speed, shell color availability, but all i get on my dat | tapes is "Adoption of newly developed superfine ceramic armor | metal-particle magnetic material achieves superb durability and high | output. Reproduces excellent high-fidelity digital sound even after | repeated use." well i would certainly *hope* so!) There are no interrecord gaps on DAT tapes. That isn't the way they work. It doesn't really matter what block size you use, as long as it is a multiple of 512 bytes, aside from OS efficiency issues. (Well, if you do a LOT of small tape files, you really want multiples of the frame size, which I don't remember off the top of my head.) Most of the data DAT drives have very large (512Kbyte for the Archive, I don't know about the TLZ) onboard buffers to increase the amount of time they spend streaming. 60 meters is far and away the most common tape length for DAT. This is the commonly cited 1.2 or 1.3 Gb capacity. 90 meter tapes are just starting to become available, and the drive vendors are just completing their fullblown tests, with pretty much uniform good results. This is commonly referred to as 2Gb capacity (or sometimes 8 Gb assuming an average 4:1 compression on newer drives that support compression in the drive; 2:1 or less compression is far more realistic...). You can get the full tape specs from the Audio DAT specs, or from the drive manufacturers, although it helps to be an OEM or large customer :) -- Dave Olson Life would be so much easier if we could just look at the source code.
aej@manyjars.WPI.EDU (Allan E Johannesen) (05/18/91)
On 17 May 91 07:52:40 GMT, olson@anchor.esd.sgi.com (Dave Olson) said: olson> Sender: news@odin.corp.sgi.com (Net News) olson> There are no interrecord gaps on DAT tapes. That isn't the way olson> they work. It doesn't really matter what block size you use, olson> as long as it is a multiple of 512 bytes, aside from OS olson> efficiency issues. This is interesting. I no nothing of the DAT technical details; I just considered myself lucky to be able to obtain one. Lacking any guidelines for dump, I wrote a stupid program which writes blocks until it gets an error, then prints the block count. For 10,240 byte blocks (the size which DECstations write during dump and rdump), I found I could write 107,528 blocks, thus 1,101,086,720 bytes. At a 32,768 byte blocksize (the size used by a different UNIX box during rdump), I found could write 39,792 blocks, or 1,303,904,256 bytes. I did no other experiments, having no other uses for the drive. I had assumed there was some IRG-similar situation at work here, since ~10% more data will fit at the larger blocksize; since this is apparently not due to gaps, it must be due to something else.
olson@anchor.esd.sgi.com (Dave Olson) (05/22/91)
In <AEJ.91May17171945@manyjars.WPI.EDU> aej@manyjars.WPI.EDU (Allan E Johannesen) writes: | On 17 May 91 07:52:40 GMT, | olson@anchor.esd.sgi.com (Dave Olson) said: | olson> Sender: news@odin.corp.sgi.com (Net News) | | olson> There are no interrecord gaps on DAT tapes. That isn't the way | olson> they work. It doesn't really matter what block size you use, | olson> as long as it is a multiple of 512 bytes, aside from OS | olson> efficiency issues. | | This is interesting. I no nothing of the DAT technical details; I | just considered myself lucky to be able to obtain one. Lacking any | guidelines for dump, I wrote a stupid program which writes blocks | until it gets an error, then prints the block count. | | For 10,240 byte blocks (the size which DECstations write during dump | and rdump), I found I could write 107,528 blocks, thus 1,101,086,720 | bytes. | | At a 32,768 byte blocksize (the size used by a different UNIX box | during rdump), I found could write 39,792 blocks, or 1,303,904,256 | bytes. Hmm; perhaps a problem with the way the driver is written, or some brain dead firmware on the drive. On an Archive Python, I get the same capacity (+- 200K, which could be accounted for by just 2 write retries), no matter what block size I use. The tlz04 is a DDS drive, just like the Python, so it SHOULD behave the same way; the actual way data is written on the tape is supposed to be identical. -- Dave Olson Life would be so much easier if we could just look at the source code.