[Info-vax] TK50 - this is annoying...
Johnny Billquist
bqt at softjar.se
Thu Oct 18 18:33:47 EDT 2012
On 2012-10-18 21:28, glen herrmannsfeldt wrote:
> Johnny Billquist <bqt at softjar.se> wrote:
>
> (snip, someone wrote)
>
>>>>> I once met someone who had used DECtapes and he had been very impressed
>>>>> by them in their day, but he was at least 20 years my senior. IIRC he
>>>>> described some mechanism where they skipped alternate blocks when
>>>>> reading or writing so that the tape speed could be higher, and those
>>>>> skipped blocks were used when the tape was travelling in the opposite
>>>>> direction.
>
> (snip)
>> I think it's time we kill the just created myth of blocks written
>> backwards, and what not. That has, as far as I know, never been done.
>
> (snip)
>> Writing blocks backward would be more headaches that it would be worth,
>> not to mentioning, as I did before, that computers can keep the tape
>> spinning without missing blocks, so there is no need from an
>> optimization point of view.
>
> It has one other advantage that hasn't been mentioned, which is
> that the logical end is near the logical beginning.
Not really, according to the latest suggestion, which would have the
blocks written:
0,2,4,6,8,9,7,5,3,1, with the odd blocks written in reverse.
So, the tape would, in the end, have the blocks in order, just that the
odd blocks were written in reverse. (Think about it.)
> If, for example, you wanted to build a data logging device which
> would keep the last N (one tape full) entries, that could be an
> advantage, as there would not be a rewind delay at the end.
Nah. If you really want to optimize for such usecases, then I think it
would make more sense to design a layout of your own, for your specific
needs.
And no matter in which order you have the blocks, you'll come up with
some degenerate use case where it is totally suboptimal.
>> If people actually thought about it... I mean, a PDP-11 could keep a
>> disk fed with data without missing blocks, and disk blocks pass by much
>> faster than tapes...
>> (Heck, I could probably keep a disk fed data on a PDP-8 as well, if I
>> thought about it.)
>
> As I mentioned before, the use of Read Backward on IBM drives allowed
> for sort programs to avoid the rewind time. As you fill the tapes
> with blocks of sorted data, and then later read them back for merge,
> it doesn't matter what order the blocks come back in.
>
> The interleaved reversed blocks form also satisfies that. Note that
> it isn't just the speed that you can write the data, but also the
> speed that you can compute what to write or process what you read.
Nope. See above. For this to be true, you should instead have the blocks
ordered this way:
0,9,1,8,2,7,3,6,4,5
with the alternate ones written in reverse. Which means you'd write
0,1,2,3,4,5,6,7,8,9, and reverse direction after 4, while skipping one
block after each written block.
So, in low level terms, it would be:
write block 0
skip block
write block 1
skip block
write block 2
skip block
write block 3
skip block
write block 4
skip block
reverse
write block 5
skip block
write block 6
skip block
write block 7
skip block
write block 8
skip block
write block 9
skip block
(back at the start)
But since blocks on a DECtape are numbered when formatting, and the
formatting just runs through the tape from start to end, the blocks on
the tape will be numbered 0,1,2,3,4,5,6,7,8,9. Which also means that the
above suggested idea for writing would mean you need to get a map of
which logical blocks maps to which physical blocks. Not forgetting that
you need to know when to switch over from forward to reverse operations.
And in general, this would just about half the speed of your DECtape.
Simply because reading all the data on the DECtape now requires you to
run over the tape two times, while without this scheme you'll read all
the tape by running over it one time.
Johnny
--
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
More information about the Info-vax
mailing list