Tape backup performance on 386 ISA/EISA systems

Martin Weitzel martin at mwtech.UUCP
Sat Jun 2 05:49:04 AEST 1990


In article <1060 at sixhub.UUCP> davidsen at sixhub.UUCP (bill davidsen) writes:
>In article <1990May30.132457.6117 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:

[about keeping a streamer streaming and the
influence of fragmented disk  files systems]

>| 2. The performance of the disk due to optimizations will probably have
>| little performance effect on the overall perforance on the tape write, since
>| the tape write is the limiting factor.
>
>  I'm sorry, this is just totally wrong. You must never have had a
>fragmented disk. I have seen transfer rates as low as 300kBytes/sec with

Isn't the best streaming transfer rate (for QIC-02) something around
85 KB/sec? A test programm which keeps my streamer streaming at least
seems to show this as "best rate". If the above `300kByte/sec' refer
to the disk transfer rate (as I understand the poster), it is more than
three times faster than the best tape transfer rate and with decent
buffering it should be no problem to keep the tape streaming.

IMHO the problem is really not the disk, but within the drivers or
interrupt priority schemes or something similar. I did some
experimenting with a small program that did not read the disk,
and had no problem keeping the tape streaming ... until I switched
between my virtual screens, which sometimes caused a stop of the
tape. It might be that switching screens requiered paging something
in and that some disk accesses caused the tape to stop. But screen
output seems to have the same effect (there are more stops of the
tape if I use cpio with "-v").

If I can achieve an average data-rate of several hundred KB/sec when
reading the disk (which IMHO uses *no* DMA on a typical PC), why can
I not achieve less than 100 KB/sec with writing the tape (which uses
DMA, at least on my system) - may it be that interrupt reaction is the
problem? Let's do some quick calculations: As I read my "space.c" for
the tape driver, it uses four 32 KB buffers (my experiments supported
this assumption). This should allow for around one full second to
fill one buffer again (in the worst case) and this should never be
much of a problem for an 80386, even if the writing process is preempted
for a moment. Of course, optimal usage of buffers would require an
early return from the write, some time before the buffer is completly
written, and that may cause problems with "End-Of-Tape"-detection.

I don't know enough about QIC-02 drives to decide which requests
must be issued within a short time window to keep the tape streaming.
(Also "End-Of-Tape"-problems may dictate a non-optimal strategy.)
But the only explanation for the stops of an otherwise fully
streaming tape when switching between virtual screens is that
there is a relatively long part of kernel code executed with high
priority in this situation.

Well, I would happily accept sluggish character echo or some delay
in switching my virtual screens during streamer operation, but I
know that it would require the driver source, if this trade-off
is feasible at all. May it be, that the disk has a too high priority
to keep the tape streaming? This would be not so wise, as the disk
generally can quickly catch up with the tape - except of course, there
is some reason that bytes must quickly transfered out of the controller
under some circumstances, but if the disk controller buffers at least
one full sector, I can see no reason for this.

Do we need somthing similar for tapes as the FAS-Driver is for serial
lines, so that some kind individuals like Uwe Doering can produce an
optimized "Final Tape Solution"?
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83



More information about the Comp.unix.i386 mailing list