[Info-vax] TK50 - this is annoying...

[John Wallace]

On Oct 19, 10:08 pm, Johnny Billquist <b... at softjar.se> wrote:
> On 2012-10-19 20:05, Bob Koehler wrote:
>
> > In article <k5rnkc$7o... at Iltempo.Update.UU.SE>, Johnny Billquist <b... at softjar.se> writes:
>
> >> The fastest tapes on a PDP-11 is the TU77, which writes at 125 ips. At
> >> 1600 bpi, that means it writes 200,000 bits per second per track, so
> >> approx 200 KB/s. And this is disregarding the block gaps, where it will
> >> pause.
>
> >> Are you saying that no disks you had could exceed that?
>
> >     We had RM03, I think, and TU45.  Out engineer insisted the TU45
> >     was faster.
>
> It was not.
>
> >> A normal RP05 or RP06 will transfer 806 KB/s, just as comparison.
>
> >     What kind of delay do you get when the disk does a seek?  That
> >     could kill our application.  It was hard real-time, get behind once
> >     and you failed.
>
> Seek will probably kill you, I bet. Unless you write to the disk without
> a file system, you have little control over placement and other issues.
> But assuming you could just write to disk blocks, in sequence, then that
> would have given you better performance than a tape. And, as I said at
> the beginning, you could keep the disk writing without missing the next
> block, and having to wait a rotation.
>
> >> And both the TU77 and the RP drives hang off massbus, so the speed
> >> outside of the drive have the same restrictions, so no way the disk
> >> could ever be slower than the tape.
>
> >     MASSBUS?  We din't have no stinkin' MASSBUS.  These were UNIBUS
> >     systems.
>
> :-)
> Both the RM03 and TU45 are also massbus devices. Massbus is (was) an I/O
> bus, not a computer bus. For a PDP-11, you used either an RH11 or RH70
> to connect your massbus devices to the Unibus. For VAXen it was things
> like the RH750 or RH780.
>
> Oh, and the RH11 was the only one which actually sat on the Unibus. All
> the others had their own connections more directly to the cpu and memory.
>
>         Johnny


Average seek time of disks from RM03 to RA81 seems to be around 30ms.
Nominal transfer rate was around 1MB/s on the RM03, maybe twice that
on the RA81, but for safety let's assume a sustained application-layer
data rate of 1MB/s. So for a 30ms seek (far less than the maximum
seek) you would have to be able to buffer 30KB of data, and then be
able to catch up again afterwards. Far from impossible, given enough
memory and clever coding, but not exactly simple or comfortable
either.

The RT11 file system used an extremely simple file system in which all
files were contiguous, in part because it was simple (ie compact code)
and in part because it meant that realtime support was easier - no
middle-of-file seeks needing tens of Kbytes of buffering. It also
meant that if a disk had enough free space, but it wasn't all
contiguous, any attempted allocation request which was bigger than the
largest contiguous free space but smaller than the total free space
would fail, and thus people might want to use the provided utility to
SQUEEZE it all into one big chunk from time to time.

If you'd like to learn a little more about RT11, RT11 V5.3 seems to be
freely downloadable for use with SIMH, e.g. for use on your favourite
Android phone. No 30ms seek problems or shortage of a few kBytes of
memory there.

The tradition of disk defragmentation continues to this day, although
Windows defrag (at least prior to Win7) at least drew prettier
pictures than RT11 SQUEEZE.