ejk@uxh.cso.uiuc.edu (Ed Kubaitis) (08/10/90)
An 8mm tape drive on an RS/6000 running AIX 3.1 appears to take ~30 seconds doing *something* when opened at load-point. The documentation I have describes a "retension on open" option, but this delay is encountered even when a device name for "no retension on open" is used. Further, this option seems to refer to QIC tapes, not 8mm, anyway. Does anybody know what's causing this delay? Is it hardware or software, and is there a way to prevent it? 2 other questions about 8mm: What are "extended file marks" and the pros & cons of using them? Is there something in 8mm recording comparable to the ARA/AGC "burst" written at beginning of tape in 1/2" 6250 GCR recording? That is, does one compromise data reliability on 8mm tapes by appending data to an existing tape on a different drive? Would appreciate either answers or pointers to people or documents with answers. Thanks in advance! ----------- Ed Kubaitis (ejk@uxh.cso.uiuc.edu) Computing Services Office University of Illinois, Urbana
franfh@aplvax.jhuapl.edu (Fran Horan) (08/10/90)
In article <1990Aug9.183901.7884@ux1.cso.uiuc.edu> ejk@uxh.cso.uiuc.edu (Ed Kubaitis) writes: >An 8mm tape drive on an RS/6000 running AIX 3.1 appears to take ~30 seconds >doing *something* when opened at load-point. The documentation I have >describes a "retension on open" option, but this delay is encountered even >when a device name for "no retension on open" is used. Further, this option >seems to refer to QIC tapes, not 8mm, anyway. > >Does anybody know what's causing this delay? Is it hardware or software, and >is there a way to prevent it? > Ed, Is the tape drive an Exabyte EXB-8200 8 MM Cartidge Tape System ? I have observed a 30 second delay for this tape drive to get the first write onto tape. The Exabyte Interface User Manual (Rev.01, page 97) describes the actions that the drive is taking during this time: "6.3.4 First Write at LBOT When the data cartridge is loaded, the tape is positioned at LBOT, and the INITIATOR issues a WRITE command, the following operations will occur: 1. Data is accepted from the INITAITOR into the CTS buffer until the motion threshold is reached; or a WRITE Filemark, REWIND, LOAD or UNLOAD command is received by the CTS. 2. The drum rotation is started and the tape is rewound to PBOT and then positioned prior to LBOT. 3. As the LBOT is approached the ERASE head is activated and the new LBOT is written. 4. Data is then taken from the CTS buffer and written to tape. 5. When sufficient data has been removed from the CTS buffer, additional data is accepted from the INITIATOR. " This characteristic is a problem for the programmer who wants to use this drive at its rated data rate capacity of 240 kbytes/sec as quick as possible. There are several things that I did to handle this problem. I was mainly concerned with trying to write to the drive as fast as possible. I got the tape head through these steps and past the LBOT by doing the following operations before declaring the tape drive to be ONLINE and ready to take host computer commands: 1. Load tape. (tape is now at BOT) 2. READ tape 3.1 If drive just read a FILEMARK, SPACE back 1 Filemark. 3.2 If drive just read data, REWIND. 3.3 If drive just read blank tape, WRITE Filemark. SPACE back 1 filemark. The tape head has now gone through the "First write at LBOT" steps. If step 3.1 or 3.3 was true, the tape head is *after* the LBOT, but is in *front* of a filemark. I now declare that the drive is ONLINE. If the host computer sends a WRITE command, I re-write the filemark I'm in front of, then I write the data record I just got from the host computer. This takes approx 20 seconds, so I have saved 10 seconds. If the host computer's first command was a READ, I read the filemark, ignore it, and then read the tape again for the first record. If you know in advance that your first command to the drive will be a WRITE, then you could move the tape head off BOT by WRITEing a bogus Filemark or data record at BOT, and leaving the tape head *after* that bogus write. Then you would have at most a 5 second delay (see page 95, Drum Motion Suspension) after the first WRITE comes in before real data goes to tape. You should also try to buffer as much data as possible while you are waiting for the drive to actually start putting data to tape. If you know the first command is always a WRITE, you can reduce the delay significantly, and the code is easy to write. If you have to postion in front of the Filemark, you don't reduce the delay as much, and you need to do more complicted coding. In both cases you may also have increased the complexity of other programs that read these tape and have to ignore empty files at BOT. Consider the reduction in delay versus the increase in code complexity before jumping in to code this up. If other readers have suggestions please let us know. I'm not satisfied with the 20 second delay I endure now. Fran Horan franfh@aplvax.jhuapl.edu