Pertec Tape Drive Interface Musings

[Johnny Billquist]

On 2015-06-10 11:00, Dave G4UGM wrote:
>
>
>> -----Original Message-----
>> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Johnny
>> Billquist
>> Sent: 10 June 2015 09:39
>> To: cctalk at classiccmp.org
>> Subject: Re: Pertec Tape Drive Interface Musings
>>
>> On 2015-06-10 09:47, Dave G4UGM wrote:
>>> Mark,
>>>
>>>     Traditional 9-track tapes are always written block-by block with a "short"
>>> gap between the records, WikiPedia say 0.6" for 1600BPI which sounds
>>> about right. From what I remember as tapes are not the most reliable
>>> medium the process was to have the read head after the write head so
>>> the tape could be read and checked as it was written. If an error was
>> returned the "system"
>>> would backspace, erase the bad block to create a "long gap" and the
>>> try again. Looking at the first MAN page for TAR I found it says it
>>> writes
>>> 20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
>>> of 10% of the tape in gaps, assuming the tape is perfect.  You can
>>> write longer blocks but then the amount of wastage when you write a
>>> bad block goes up.
>>
>> I don't think it really is that you have a long gap when you rewrite a "bad"
>> block per se.
>
> What else do you get then? I can see from the IBM 2400  manual here:-
>
> http://bitsavers.trailing-edge.com/pdf/ibm/24xx/A22-6862-4_2400_Series_Magnetic_Tape_Units_OEM.pdf
>
> that write checking is accomplished by reading. There really isn't anything else you can do when a write fails...
> .. well you can retry the write...

You misunderstood me. It's not that you do not get a larger gap, but you 
can get a large gap even without an error. It's not an explicit error 
recovery strategy, but a fallout from having to stop, rewind, start and 
write again.

>> But you get long gaps when you stop/start.
>
> Not on Vacuum Column drives. The columns provide enough mechanical buffering to start and stop within the Inter Record Gap.

The mechanical buffering don't have anything to do with this. It's a 
question of how fast you get the tape up to speed across the heads.
Now, admittedly, vacuum column tape drives have an advantage that you 
don't have to accelerate the reels that violently, since the vacuum 
columns gives you some time to speed up the reels. But the acceleration 
of the tape across the head is simply a question of friction of the 
drive wheel for that section of the tape, and the mass of the tape itself.

However, since vacuum column tapes have a much higher tape speed across 
the heads than direct drive or spring tensioned tape drives, you get 
into the same cat and mouse game anyway. Acceleration of tape across the 
heads is the issue. How much tape will pass before you reach top 
velocity, and how precise is this? A larger gap allows for more 
variation. If the tape is already running at full speed, and you are 
just continuously writing, then you can easily control how long gap you 
create, and can create minimal ones.

	Johnny

>
>>   And a rewrite
>> implies that you will get a stop/start situation.
>> But in case you already were going stop/start, the gap will not be extended
>> any longer.
>>
>> You want to stream the tape, meaning you both get short gaps, and also
>> much higher transfer rates, as the stop/start really cause the tape to be slow.
>> But for streaming mode to work, you need to feed data to the tape fast
>> enough. And with that, I mean that when one block operation is finished, the
>> command for the next one needs to happen very quickly, or else the tape
>> will need to stop.
>>
>> This also means that you do not always have a short gap with an error free
>> tape. The gap size depends on whether the tape was running at speed or
>> not, when the write starts.
>>
>>> So I guess to answer your question. Operating systems and tools expect
>>> a block level interface to tapes. You need to duplicate this in your
>>> interface.
>>
>> Yes. Just as systems expects a block level interface to disks.
>> The "stream of bytes" concept is in many cases an artificial construct handled
>> by the OS (Unix), and not the hardware.
>>
>> 	Johnny
>>
>>>
>>> Dave
>>>
>>>> -----Original Message-----
>>>> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mark J.
>>>> Blair
>>>> Sent: 10 June 2015 08:34
>>>> To: General Discussion: On-Topic and Off-Topic Posts
>>>> Subject: Pertec Tape Drive Interface Musings
>>>>
>>>> I was looking at a couple of documents describing the Pertec tape
>>> interface;
>>>> the manual for my Kennedy 9610 tape drive, and a nice reference by a
>>> fellow
>>>> with a rather familiar name:
>>>>
>>>>       http://www.sydex.com/pertec.html
>>>>
>>>> According to my Kennedy manual, issuing a read command causes the
>>>> drive to return one block of data. I can see how that would be used
>>>> in block- oriented applications in which blocks may be randomly read,
>>>> written and
>>> re-
>>>> written on the tape. But most of my magtape experience has been using
>>>> the tapes in a streaming mode, such as when reading/writing one or
>>>> more tar archives separated by file marks.
>>>>
>>>> When writing a tar archive on a magtape from a Unix system, is the
>>>> archive written as a sequence of fixed-size blocks? Or is the entire
>>>> tar archive effectively written as one continuous block which must be
>>>> streamed with no repositioning?
>>>>
>>>> I'm curious because I'm daydreaming about how to build a tape drive
>>>> interface controller, and I wonder whether it might need to
>>>> potentially stream an entire tape in one go vs. being able to safely
>>>> assume some maximal block size.
>>>>
>>>> --
>>>> Mark J. Blair, NF6X <nf6x at nf6x.net>
>>>> http://www.nf6x.net/
>>>
>>>
>>
>>
>> --
>> Johnny Billquist                  || "I'm on a bus
>>                                     ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol