hedrick@geneva.rutgers.edu (Charles Hedrick) (03/03/90)
Original-posting-by: hedrick@geneva.rutgers.edu (Charles Hedrick) Original-subject: Re: SCSI on Sun Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) >The glossy on the 4/60 on the otherhand talks about fast synchrononous >scsi. Does the "esp" in fact implement the draft SCSI-2 standard, and >support the fast synchronous option? Do any of the Sun disks take >advantage of this? Is the fast SCSI option a driver issue, or is it all >hardware? > >Is it possible that a 4/60 would make a better SCSI fileserver than a VME >Sun 4 with the "si"? It's very hard to give completely reliable answers comparing various configurations without a rather large benchmarking lab. Sun should really be the one to tell us how the I/O performance on various configurations compares. But Rutgers has lots of Suns, and I've recently been trying some simple tests on a bunch of them. In general I find that on a test designed to show up transfer rate differences (reading the raw disk with dd), SMD is a factor of two faster than SCSI, and IPI (on a 390) is a factor of two faster than SMD. I don't see much difference between the SS1 builtin SCSI, the builtin SCSI on a 4/370, and the Ciprico VME SCSI controller. However to the extent that there is a difference, the SS1 is slightly faster than the Ciprico controller. Results for the 4/370 are hard to evaluate, because the users seem to keep a continuous load on it. There's one indication that it may be slightly faster than the SS1, but I can't be sure. There are at least two differences between this simple test and real use as a file server: (1) in real situations, you're going to be moving the head around, not reading the raw disk sequentially (2) for a file server, the NFS protocol is going to take some time, and the Ethernet (and Ethernet controller) is going to be a performance limit. In an attempt to evaluate the effects of this, I tried "mkfile 2m" over NFS, and I also tried reading a large file over NFS using dd (being careful to purge it from the caches on both machines first -- which you can do by cd'ing to the file system and trying to umount it. Umount will fail, but it will purge the cache entries for that file system.) Again, this was not an attempt to do a realistic test, but an attempt to see whether I could at least construct tests where I could see performance differences among the disks over NFS. Simple sequential reads and writes seemed the most likely circumstance. The mkfile showed essentially no difference. Clearly the well-known problems of writing large files on NFS washed out any disk performance differences. Reading a large file showed a factor of 1.5 between SS1 SCSI and IPI. I'd expect this to be an upper bound on the difference you see in practice. Real usage would involve lots of seeks, which would tend to emphasize the access times of the disks (not just the access time of the disk itself, but system configuration issue that would affect the length of the disk queue, e.g. how many different disks there are on the system). My current guess -- and without more systematic testing it is only a guess -- is that the SS1 is about as good a file server as anything, at least for Ethernet. If you want an FDDI file server, I might suggest using a system with IPI disks. However you'd also have to make sure that the NFS implementation and the FDDI controller were capable of showing up the speed of the disk. At any rate, with Ethernet, I'd expect any differences in controller speed to be dominated by differences in access time (and the quality of the Ethernet subsystem). This means using disks whose seek time is fast, and configuring the system with lots of spindles. You may be better off spending your money buying lots of disks for an SS1, rather than getting a higher-end system and not being able to afford as many disks. You want to split swapping on all of your systems between two disks, use separate spindles for common used things (swap, /tmp, and /usr on our systems), and at least for servers used to supply /usr, use lots of memory on the server (though I confess that we haven't tried using lots of memory on file servers yet). Of course this doesn't answer your specific question, which is about Sun's VME "si" controller. It is certainly possible for controllers to be slow enough to affect things, even with NFS. The old Xylogics 450/451 certainly was. My comments about SCSI apply only to the controllers I tested, which are fairly new ones. As for your other questions, the 4/60 uses a standard SCSI chip. I don't have any drives that implement SCSI-2, so I can't swear whether it supports them, but I rather doubt it. Even the current SCSI spec has a synchronous option. That's what they support. However by default the driver disables synchronous operation. The header file claims that this is because there have been problems with noise when using sync SCSI in installations with long or noisy cables. It's easy enough to enable (twiddle one bit using adb). The synchronous transfer is implemented by the SCSI controller chip, but it is enabled or disabled by the device driver. I've tried things both ways. I've yet to see any advantage to using sync. Maybe the advantage only shows up with faster disks than we've got, or with lots of disks running at the same time. (I'm using the HP 97548S disks, 760MB 5.25 inch disks with 16 msec seek.) If anybody has any better data about disk/controller performance, or information about what configurations are the most cost-effective file servers, I'd sure love to hear about it. For the moment, I'm planning to use Sparcstations as file servers, and try to split usage across as many disks as I can afford.