martin@mwtech.UUCP (Martin Weitzel) (06/09/90)
Just half an hour ago the following happened with my streamer (System Info: ARCHIVE FT 60 / 80386 / ISC 386/ix Rel 2.0.2): When backing up a file system that would usually be copied at full streaming spead (~80 KB/sec) the performance was ABSOLUTELY DOWN! There were tape stops approximately every 32 KB (which is the block size the driver internally uses, for as much as I know). As I knew that performance usually was *much* better, I shutdown the system, rebooted, and - voila - speed was back again: The same file system could be copied as fast as ever. Nothing else was changed! Any ideas? As further information I should tell that I had several times the tape operation aborted (with SIG_INT from the keyboard) before the strange effects begun. Some other idea is that memory might have become too fragmented to allocate suitable buffers. (May this be a problem at all? How can I check for this if the performance drop should occur once again? Could this be cured without rebooting? Before rebooting I changed to single user mode and back, but that didn't help.) Though bringing my system down and rebooting is not much of a problem in the environment where I work, I would be glad if someone could enlighten me about what may have happened. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
cpcahil@virtech.uucp (Conor P. Cahill) (06/09/90)
In article <793@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >(System Info: ARCHIVE FT 60 / 80386 / ISC 386/ix Rel 2.0.2): >When backing up a file system that would usually be copied at full >streaming spead (~80 KB/sec) the performance was ABSOLUTELY DOWN! >There were tape stops approximately every 32 KB (which is the block >size the driver internally uses, for as much as I know). > >Any ideas? As further information I should tell that I had several >times the tape operation aborted (with SIG_INT from the keyboard) >before the strange effects begun. Several possibilities: 1. You had some process running in the background that was sucking up cpu time, which caused the delay in filling the tape buffer. 2. You ran into a bug in the driver (the Archive driver is known to have several bugs that cause the tape drive and the process talking to it, to lock up and be unavailable until you reboot the system, so this is a valid possibility). 3. You had some program running on the console that was sending out lots of output (console output is notorious for slowing down tape streaming, probably due to it being a higher priority than tape output). From your description I would *guess* that #2 is the likely culprit. >Some other idea is that memory might have become too fragmented to >allocate suitable buffers. (May this be a problem at all? How can I >check for this if the performance drop should occur once again? >Could this be cured without rebooting? Before rebooting I changed >to single user mode and back, but that didn't help.) This should not be a problem because the System V r3.2 does not dynamically allocate buffers. They are all alocated at boot time and therefore are not suceptable to memory fragmentation. >Though bringing my system down and rebooting is not much of a problem >in the environment where I work, I would be glad if someone could >enlighten me about what may have happened. When I first set up our system I had to do this about twice a week, but lately it only happens about 1 every two months or so. Part of this is due to the fact that we no longer run to end of tape (our backup software is configured to put only 56MB of data on a tape). The archive driver has a 50-50 chance of locking up if you run to end of tape. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170