Date: Fri, 05 Mar 1999 22:15:17 -0600 From: David Kelly <dkelly@hiwaay.net> To: freebsd-scsi@freebsd.org Subject: SA performance (was: rc5des slows tape thruput) Message-ID: <199903060415.WAA04371@nospam.hiwaay.net>
next in thread | raw e-mail | index | archive | help
Started this in -stable last week and got some useful suggestions such as to increase the kernel HZ, or to alter real-time priorities. Haven't pursued either as both would be useful for characterizing the problem but not for solving it. Just as my observation that rc5des was a simple way to illustrate the problem with only one tape drive. The other reason is while I installed this particular system last month its now at another contractor and I have to use it now as a regular user. :-( Background: the machine is a P-II 233 MHz with 64MB of RAM, onboard Adaptec UW-SCSI, and two Asus SC875 UW-SCSI PCI cards. Seagate 9G HD is on the Adaptec. Two Seagate Scorpion-24 DDS-3 tape drives are on each of the two SC875's for a total of 4 tape drives. We like to make tapes. I've written (copied) 180 tapes on this system in the past several weeks. What I usually do is use tcopy or dd to copy the original tape to disk. Then tcopy it to the new tapes, running 4 instances of tcopy, one per tape drive. Strangely on DDS-1 tape this runs just under 700k/sec per tape drive. But on DDS-3 it drops to 550k. Reading a single DDS-3 tape generated this way runs right at 1MB/sec. Doesn't much matter if its tcopy or tar doing the reading or writing. Tcopy DDS-3 tape to DDS-3 tape crawls at 300k/sec. Doesn't seem to matter if the tape drives are on the same SCSI controller or not. When its 5G of data and it only runs at 1/3 the expected rate, its a concern. Also when writing a tape slowly like this one puts more tape between blocks and/or causes the drive to start/stop a lot. Am guessing only one chunk of data gets queued to be written then the calling process (tcopy) blocks until the tape drive completes the transfer. Then tcopy is placed in the runable queue and restarted by the scheduler the next time around. It may be the process is blocked not because the write hasn't completed but because another chunk was queued and the tape drive reports its busy? Reading the Conner "DAT Tape Drives and Autoloaders SCSI Manual, October 1995" suggests this should not happen until the tape drive's RAM buffers are filled. These drives have 2M of RAM and should be able to suck up a lot of data before throttling. Watching with "systat -v" doesn't show any such burst of I/O. If this is the case then could CAM be interpreting the result codes from the tape wrong, that the tape really could accept more data? Preventing the user process from blocking? Reading scsi_sa.c reinforces the feeling I'm way over my head. Reading mtio(4) thought I'd found gold, MTCACHE, but I can make enough sense out of scsi_sa.c that MTCACHE/MTNOCACHE are no-ops. The Conner book says, "Buffered Mode allows the most efficient operation of the DAT drive. the drive defaults to Buffered mode." (exact quote including screwy capitalization.) Page 26. So buffered mode is the default? Then how is it disabled and/or enabled? Somewhere in physio() and sastrategy() are probably the keys to the blocking behavior. Top(1) shows the process run state is "physst". With any luck this message won't be a waste of your time and mine, and somebody will make sense of what I'm observing and produce a cure. Would expect this to increase everybody's backup performance. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903060415.WAA04371>