Path: utzoo!attcan!uunet!mcsun!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.unix.i386 Subject: Re: Tape backup performance on 386 ISA/EISA systems Keywords: tape, performance, 386 Message-ID: <770@mwtech.UUCP> Date: 1 Jun 90 19:49:04 GMT References: <1990May25.123302.26061@virtech.uucp> <1990May26..841@rdk386.uucp> <1990May30.132457.6117@virtech.uucp> <1060@sixhub.UUCP> Reply-To: martin@mwtech.UUCP (Martin Weitzel) Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 66 In article <1060@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <1990May30.132457.6117@virtech.uucp> cpcahil@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@mwtech.UUCP, voice: 49-(0)6151-6 56 83