wcs) (11/14/90)
We're planning to get a Sun server for NFS, and are trying to decide whether to get a cheap Sparcstation with SCSI, a Sparc2 with SCSI, or one of the big honking expensive servers with IPI or SMD. Are the SCSI systems fast enough? Will UNIX 4.1.1 help performance substantially on the pre-Sparc2 machines? Initially we'll have a few diskless and dataless clients, but we'd like to be able to grow a lot and also have some spare CPU around for X-terminal support, as well as a few people with 120-MB working sets that we may run on a server. We know about Auspex, but they start at $80K and we don't have a lot of client machines. Thanks; Bill -- Thanks; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ Government is like an elephant on drugs: It's very confused, makes lots of noise, can't do anything well, stomps on anyone in its way, and it sure eats a lot.
srm@Unify.Com (Steve Maraglia) (11/15/90)
In article <1990Nov14.051828.4221@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs) writes: >We're planning to get a Sun server for NFS, and are trying to decide whether >to get a cheap Sparcstation with SCSI, a Sparc2 with SCSI, >or one of the big honking expensive servers with IPI or SMD. >Are the SCSI systems fast enough? Will UNIX 4.1.1 help performance >substantially on the pre-Sparc2 machines? > Since those big honking expensive servers don't fit very well into our budget so I'm considering a SPARCstation 2 as a server. I just got off the phone with a Sun SE and have a few pieces of information that may be of interest. Besides having the highest MIP rating in the product line they have made some big improvements in I/O performance. Two big factors for the improvment are: 1. The kernel enhancements for the DataBase Accelerator package have been included in 4.1.1. 2. The SCSI interface is synchronous! Synchronous tranfers are almost twice as fast as asynchronous. -- Steve Maraglia internet: srm@unify.com Unify Corporation ..!{uunet,csusac,pyramid}!unify!srm 3870 Rosin Court Sacramento, CA 95834 (916) 920-9092
fitz@frc2.frc.ri.cmu.edu (Kerien Fitzpatrick) (11/15/90)
Why not consider a SPARCstation 2 and one of the SBus to VME interfaces. My understanding is that the Sbus to VME products can only attain 20 Mb/s (this may have changed), but I would guess that it could still keep up with the XY753 (6U) controller. Two vendors are marketing SBus to VME (Solflower and Bit3). -- Kerien Fitzpatrick Pittsburgh, PA 15213 Field Robotics Center (412)268-6564 The Robotics Institute Internet: fitz@frc2.frc.ri.cmu.edu Carnegie Mellon University
srm@Unify.Com (Steve Maraglia) (11/17/90)
>In article <ib9y6u5@Unify.Com> srm@Unify.Com (Steve Maraglia) writes: > >>In article <1990Nov14.051828.4221@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs) writes: >> >>We're planning to get a Sun server for NFS, and are trying to decide whether >>to get a cheap Sparcstation with SCSI, a Sparc2 with SCSI, >>or one of the big honking expensive servers with IPI or SMD. >>Are the SCSI systems fast enough? Will UNIX 4.1.1 help performance >>substantially on the pre-Sparc2 machines? >> > >Since those big honking expensive servers don't fit very well into >our budget I'm considering a SPARCstation 2 as a server. I just got >off the phone with a Sun SE and have a few pieces of information that >may be of interest. > >Besides having the highest MIP rating in the product line they have made >some big improvements in I/O performance. > >Two big factors for the improvment are: > > 1. The kernel enhancements for the DataBase Accelerator package have > been included in 4.1.1. > I stand corrected on item 1. by another Sun S.E. who has some additional performance comments. See below. > On Nov 14, James Litchfield - Sun Major Accounts Region SE writes: > > > 1. The kernel enhancements for the DataBase Accelerator package > have > > been included in 4.1.1. > > Only those parts of DBE directly related to the PMEG problem have > been incorporated. Other parts of DBE are not part of 4.1.1. You should > probably correct your statement. > > > You should also consider the following tidbit for 4.1.1 - I/O > clustering. > > >From the RTF: > > The Unix File System (UFS) has been modified to make use of I/O > clustering. Clustering improves sequential I/O performance by > writing files to disk in physically contiguous blocks whenever > possible. Although it has long been possible to tune UFS to write > contiguous blocks, it has rarely been done, beacuse write performance > suffers. Clustering is a different approach. > > Under previous SunOS operating systems, UFS responded to each I/O > request by reading or writing a single block (usually 8KB) of data. > Since data is written to a spinning disk and between each response > to an I/O request there is a brief time delay, it is impossible to > write contiguous disk blocks while the disk is spinning unless the > write waits for the disk to rotate back to the point of the previous > write. Writing a large file to contiguous disk blocks would require a > large number of individual I/O requests and write delays. > > In SunOS 4.1.1, UFS has been modified to cluster I/O requests into > extents and read or write an entire extent in a single I/O operation. > The size of an extent can be controlled by setting the file system > parameter maxcontig (see tunefs(8)). Since extents reduce the number of > I/O operations necessary, there are fewer delays between writes and > fewer rotational delays. > > File systems created with the newfs command use I/O clustering and > are automatically tuned for high performance. However, the benefits of > clustering may decline if a filesystem created under newfs starts to > fill > up and is heavily fragmented from the repeated addition and deletion > of files. In addition, filesystems using 4KB blocks on 8KB page systems > do not benefit from I/O clustering and are not recommended. -- Steve Maraglia internet: srm@unify.com Unify Corporation ..!{uunet,csusac,pyramid}!unify!srm 3870 Rosin Court Sacramento, CA 95834 (916) 920-9092
hitz@auspex.auspex.com (Dave Hitz) (11/21/90)
In article <1990Nov14.051828.4221@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs) writes: > We're planning to get a Sun server for NFS, and are trying to decide whether > to get a cheap Sparcstation with SCSI, a Sparc2 with SCSI, > or one of the big honking expensive servers with IPI or SMD. > Are the SCSI systems fast enough? Will UNIX 4.1.1 help performance > substantially on the pre-Sparc2 machines? For NFS servers, disk transfer-rate is less important than most people's intuition first suggests. The reason becomes clear when you look at how time is spent in an 8K NFS read using a SCSI disk: Average seek 16 milliseconds Average Rotational latency 7.5 milliseconds 8K Data xfer 4 milliseconds SCSI interrupt handling overhead 2.5 milliseconds 8K over the Ethernet 8 milliseconds ------------------ Total 38.0 milliseconds With an IPI, seek might drop to 15, and data xfer might drop to 3. This gives an improvement of only about 2 milliseconds out of 38, or about 5%. In fact, percent improvement will be even less because I've left out the time spent in processing the request in the CPU and in moving the data around the system. This argument works because NFS transfers are always 8K or less. With local access to very large files, transfer time eventually dominates and IPI starts to make sense. But for NFS, go with the cheap disks. WARNING: All of this does not mean that a SPARCstation with SCSIs will give you the same NFS performance as a SPARCserver with IPIs. What it does mean is that the SPARCserver isn't doing better because of the type of disks it's using. There are plenty of other bottlenecks in a SPARCstation to slow things down. Make your Sun salesman give you benchmark results comparing the two systems you are considering. A SPARCstation might well be able to handle the job for a while. > We know about Auspex, but they start at $80K and we don't have a lot > of client machines. Sorry about that! :-) -- Dave Hitz work: 408-492-0900 UUCP: {uunet,mips,sun,bridge2}!auspex!hitz home: 408-739-7116