bkc2@midway.uchicago.edu (Benjamin Clardy) (04/24/91)
I thought I might post a summary of the responses I received to my query on sync scsi. >Our main computing bottleneck seems to be disk speed. Specifically, we >have SAS analyzing fairly large datasets, 5MB - 150MB, so sustained disk >throughput is very important. I have tried to implement sync scsi under >4.1 changing the scsi_options in the kernel to 0x38 but I can not tell any >noticeable effect in speed. In addition, if I set the jumpers on my >M2263SAs to 4.0MB/s max transfer rate (instead of 2.7MB/s) the drive fails >to function properly. curt@ecn.purdue.edu (Curt Freeland) writes I have several of these drives at 4.0 M/s on SS2 systems running fine. >Do I need to go to SunOS 4.1.1 to take advantage of sync scsi? What type >of throughput inccrease with sync scsi can I see on a SLC? terryk@encore.com (Terence Kelleher) @ Encore Computer Corp. writes Regarding SYNC SCSI, the sync transfer does not help unless you have 2 or more disks on your bus and you are running both of them alot. Basically, even running async, SCSI outruns the media to buffer transfer time of the disk. On a read, a good disk attempts to connect to the bus when enough data has been buffered to be able to transfer all the data in one connection. ie: Try to have the SCSI transfer end just after the disk transfer ended. On a write, completion is sent ot the user only after all data is transfered to the media. Running SYNC transfer on the SCSI bus gets the data transfer phase done quicker, but does not help to complete the transfer faster. What SYNC SCSI gives you is more free time on the bus. If only one access is busy, free time is of no value. If many disks are active, the added free time means more commands can get out to disks faster. You can measure this with 2 disks busy on the bus, but it is not real significant. With 3 or 4 disks on the bus, Async gets saturated and Sync does not. This is example results of a Sync vs Async test. The units as IO operations per second. All transfers 8 Kbytes. Number of disks 1 2 3 4 5 6 Sync (5 Mbyte/sec) 52 93 118 134 141 145 Async (1.5 Mbyte/sec) 52 75 83 85 85 85 By the way, the tests I quote above were not run on a Sun. This is from a test of an Encore Multimax running 12 32532 Cpu's, running a disk test with 32 seperate processes. Its hard to get that much IO on a disk and still have the machine do real work. Most often, even on a busy system, only one or two disks will get much work load at any given time. hanson@calvin.fnal.gov (Steve Hanson) writes If you are running your machine with a SINGLE disk drive, Sync SCSI isn't going to buy you much, if anything. The real advantage of having Sync is that if you have multiple SCSI devices contending for bus time, they all get off the bus much faster. Async can be very fast if you don't have very long disk cables. samg@midway.uchicago.edu writes Since an SLC is effectively the same as a SS1, and since Sun claims that the SS1 isn't fast enough to do sync scsi, you may not have much luck no matter which version of SunOS you run. I'm told it can be done, but the quality of the cables is crucial. I'm currently running a FJ2263SA in sync mode (all jumpers closed) off a 1+ with no trouble at all, and getting about 3.6 mb as the max transmit rate. Try it on your IPC. bernards%ecn.nl writes I Have an SLC running 4.1.1 and have a WREN VI 660 MB disk attached. I get 4MB/sec tranfer rate. Strangely, a IPC with an external 660 SUN Disk runs at 3.9?? MB/sec A SS1 does not run in sync mode in 4.1.1 :-( >What other advantages does 4.1.1 have over 4.1? samg@midway.uchicago.edu writes Tons of bugs fixed. (You'll still need patches however) I'll be creating a 4.1.1 patch archive on midway within a week or so. guy@auspex.com (Guy Harris) writes Open Windows 2.0 is bundled with it. MS-DOS file system as a VFS type is bundled in (you can mount DOS floppies on your Sun and access them from UNIX - it does its best to make them look as much like UNIX file systems as it can; this does not, of course, include translating *file* formats - you still see CR/LF - but it does handle directories, albeit with the traditional 8.3 limitation on file names). I/O clustering, wherein on the faster machines you can have a file system rotational delay of 0 (or 1, or whatever - basically, put block N+1 of a file next to block N), and the system will try doing I/O to the file in big contiguous chunks (local I/O; NFS I/O is still done in 8K chunks or so). Bug fixes to the "/tmp" file system to make it much faster. Rewhack of the low-level support code for the Sun MMU to make it handle some page faults for pages that are in memory, but not mapped in the MMU because there isn't enough room in the MMU, more efficiently. Assorted bug fixes, and some miscellaneous enhancements. <Regarding my diatribe on short Sun warranties and my bad experience with> <Sun supplied internal drives> curt@ecn.purdue.edu (Curt Freeland) writes I have been yelling at Bob Fernander (Chicago office sales manager) and the Indy office for some time now. I have also yelled at people up the ladder at Sun that they should pass on the vendor warrantee with the stuff they re-sell (Maxtor, Hitachi, ...). This would make the customer happier if they could get a replacement on the drives from the original manufacturer, instead of getting screwed by Sun (again). No sh*t. I recently was asked what price the Sun drives would have to be before I would buy them. My response? "How long is the warrantee?". When told 90 days, I said forget it, I dont want them. Why bother when I can get Fujitsu, or HP drives with 5 year (48 hour replacement) warrantee, and other brands with 3 year warrantee? gord@cs.ualberta.ca (Gord Urquhart) writes We had one of our sun supplied Micropolis drives fail @ about 98 days and of course Sun would not fix it. But the other thing Sun did was NOT tell us that Micropolis warrants their drives for a year. So take a look and seen if there is a manufacturers warranty on the drive. THANKS to all who responded. Benjamin bkc2@midway.uchicago.edu