funke@ai.toronto.edu (Mark Funkenhauser) (02/24/88)
In an article from agnew@trwrc.UUCP (R.A. Agnew), he writes: >In article <325@gen1.UUCP> tyler@gen1.UUCP (Tyler IVANCO) writes: >> I believe that this is a problem of the operating system getting >>in the way of the I/O from/to disk/tape. On the UofT 4.2 port for the >>ICM, it is quite easy to stream the tape drive using tar with a large >>blocking size. e.g. >> tar cbf 1024 /dev/rmt4 . >Yes, this helps but it does not fix it. No, its not the operating system. YES, it is the operating system (at least on the 4.2BSD port)! >The real problem is that the brain damaged SCSI controllers that Sun and >others used in those old designs did not support the full SCSI prrotocol >and thus cannot release the bus to the CPU while the transport is in >motion. This is the reason why you can't stream with them. Replacing the >ACB2070 with a decent SCSI controller is part of the real answer. >Note that the Sun3-50 can release and this feature is supported by Sun OS >version 3.4. Sun3-50 systems used the ACB-4070 disk controller and an Emulex MT02 tape controller. 1) The SCSI controllers are NOT brain damaged. The ACB-4070 disk controller that the Sun3-50 uses is intended for a single user PC system, NOT a multi-user UNIX system. The Emulex MT02 tape controller DOES support reconnect/disconnect! 2) It is the DISK controller that did not support the disconnect/reconnect SCSI protocol. Therefore the Sun OS did not program the SCSI host controller to support the disconnect/reconnect function. Therefore, the tape controller never released the bus! When we tried to plug in an ACB-5500 ( an Adaptec disk controller that DOES support disconnect/reconnect) we found that the system HUNG! We eventually did get the ACB5500 to work, but only after disabling (patching) some flag in the kernel that was related to handling disconnect/reconnect in the SCSI host controller driver. I understand that this is all fixed in 3.4, but we have not tried it yet. >The National board has a similar problem. WRONG! The ICM3216 systems that we received NEVER experienced the problems that occured on the SUN. We use the Emulex MT02 tape, Emulex MD01 disk and ACB-5500 disk controllers. These all support reconnect/disconnect properly. [ We, are several people at U of Toronto, including those of use who have written scsi drivers for 4.2BSD and other local OS's for the ICM3216 ] Now, back to the streaming problem. The following discussion pertains ONLY to the 4.2BSD port from U of Toronto. I can only speculate that same problem (and solution?) exists in System V. I have found that by using the 'b' option in tar AND dump, the tape will stream on writes! (I tend to use 2000 for large writes) The blocking factor ('b' option) is important, since this limits the maximum amount that the tape can possibly stream. (By default, tar will use the max. of 20 as the blocking factor, which is much too small. On System V.3 and V.2, the default is 1, and the max. is 20. Cpio is even worse, the B option only gives you 5K blocking factor. ) On reads, however, the tape will only stream up to a maximum of 64K at a time (or less, if the blocking factor, is less than 128). The reason for this, is that even thought the user (tar program) has requested a read (of say 2000 blocks), the kernel automatically splits up the transfer into 64K pieces. The 64K of user virtual address space is locked down in memory, and then the transfer is executed. (i.e. only 64K can be locked in core at any one time) Therefore SCSI read requests of only 64K are sent to the tape controller. On most tape controllers, there is usually 8K of buffer space. The controller usually allows the buffer to partially fill up, before reconnecting with the host to transfer the data to the host. During the read of 64K, the host controller is quick enough to receive the data to keep the tape streaming. BUT, in between the 64K SCSI read requests from the host, the host is ensuring that 64K of user address space is locked in core, and in this time, i think that the tape controller has overflowed the controller buffer, and this is when the streaming stops. I have found that by reducing the lock down size to 16K, less time is spent locking pages in core so that the controller's buffer does not overrun, and the tape can successfully stream for the full 2000 blocks. [ the fix in tc.c (the tape driver): the 64K limit is enforced by a routine called "minphys()" which is passed as a parameter to physio(). In the tape driver, I have changed the call to physio() so that a new minphys() is passed (tminphys()), which uses a 16K limit. ]
agnew@trwrc.UUCP (R.A. Agnew) (03/01/88)
In article <1988Feb23.204117.20583@jarvis.csri.toronto.edu>, funke@ai.toronto.edu (Mark Funkenhauser) writes: > > When we tried to plug in an ACB-5500 ( an Adaptec disk controller that > DOES support disconnect/reconnect) we found that the system HUNG! > We eventually did get the ACB5500 to work, but only after disabling > I understand that this is all fixed in 3.4, but we have not tried it yet. > If you check my article I distinctly said that you must use version 3.4! > WRONG! The ICM3216 systems that we received NEVER experienced the problems My apologies. I didn't verify the reports that the board didn't disconnect. I still maintain that using the b switch doesn't enable streaming, it only masks the problem by transferring a huge block. Where did you ever get the idea that the Sun3's wre PC's? I have dozens of users hooked up to them. A Sun4 can support 32 - 64 users as well as any Vax!