486 computers and Unix

[Wm E. Davidsen Jr]

In article <2201 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:

| The reason is obvious -- you were using the special device files that imply
| tape buffering to access the tape. When you do this, the driver allocates a
| number of pages of memory to buffer IO to/from the tape, so as to give the
| illusion of asynchronous operation, and make the tape stream. If there are
| not enough (contiguous, usually) pages to sustain the buffering, which is
| easily the case on a loaded machine, problems happen -- the tape driver waits
| for these pages, and looks locked up.

  This is the source of the message "system too busy for efficient tape
operation" you sometimes get when trying to start a tape job. I wonder
who SCO didn't have a clue on this one.

| This problem occurs, as far as I know, with nearly every buffering tape
| driver around. Buffering should not be done in the driver at all -- it
| should be done by a user utility. If the kernel were well implemented, this
| would not just work better, it would also have small overheads.

  Say what you will, the SCO driver keeps the tape streaming, the
standard v.3.2 drivers don't. However, the SCO SCSI drivers have not
shown the same throughput, to say the least. With the disk on the same
controller I could (maybe) see it, but a 670MB ESDI drive and DAT tape,
on separate controllers, still don't stream the tape. Even with media
changes the Wangtek 150 (5 tapes) runs faster in real time. Of course we
run it overnight, so it isn't a problem.
-- 
bill davidsen - davidsen at sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me