olson@anchor.esd.sgi.com (Dave Olson) (05/16/91)
In <1991May15.001955.4146@corpane.uucp> herman@corpane.uucp (Harry Herman) writes: | In <41691@unlisys.in-berlin.de> rot@unlisys.in-berlin.de (Robert Rothe) writes: | I don't know anything about the SGI, but in order to use synchronous | SCSI, both the controller and the drive have to be willing to do it. | We purchased a disk drive once that was willing to do synchronous | SCSI, but since the controller was not willing to do it, we had to | jumper it off. I also do not know if you can do both synchronous | and asynchronous SCSI on the same cable or not. If not, then all | drives on the cable AND the controller would have to be willing to | do synchronous SCSI. | | Harry Herman | herman@corpane Well, this is partly correct. Until very recently, due to confusing language in the SCSI 1 spec, almost NO targets initiated synchronous negotiations. Therefore the SGI driver didn't handle it. In 4.0, the standard SGI SCSI driver DOES handle target initiated synchronous negotiations, but only if you have the newer version of the SCSI chip. The new version is found on all 4D25's, all 4D35's, the most recent 4D20's, and machines with the IO3 (power channel board). The hinv command will show either WD33C93, or WD33C93A. The A version is newer. The older chip has a bug that prevents target initiated sync negotiations from working on our hardware. You can mix synchronous and async scsi devices on the same bus, with no problems at all (a good thing, since only the newest tape drives support sync mode!) on systems that support sync scsi. -- Dave Olson Life would be so much easier if we could just look at the source code.
neese@adaptx1.UUCP (05/16/91)
>/* Written 9:15 am May 14, 1991 by utstat.UUCP!tg in adaptx1:comp.periphs.s */ >I too bought a 2266 in the hopes of connecting a BIG, FAST, and CHEAP >drive to what is a relatively fast machine (4D220). > >The drive came configured from our vendor and it almost worked. >A lot of hours later I had a drive that ran. But it ran SLOWWW. >Top speed of about 900KB/sec. Way short of the rated 5MB/sec. > >>STUFF DELETED<< > >Still not satisfied I'm trying to get the very last drop of performance >out of the drive. Why won't it run any faster than 900KB? The drive is >rate for 2MB/sec in asynch mode. > >A call to Fujitsu indicated that > "in my configuration 1MB/sec was a good number." > >The nuance of the phone call was that unless you had some VERY good >SCSI equipement your aren't going to get anything near 2MB/sec. > >>STUFF DELETED<< Bitten by the marketing bug again. What is said or not said in the SCSI brochures about devices is; the continous data rate. Although some of the higher quality manufacturers are starting to put this into thier literature, most do not. While they will all virtually claim 2MB/sec async and 5MB sync, if you look a little closer, you may find this data rate is *burst mode* transfers. Some won't even document this, but most do. Another thing to realize is; The effective data rate. Specifying the burst or continous data rate for the device may be measured only during the data phase and will probably not include the other phases the SCSI bus goes through which will lower the overall data rate. The manufacturer of the peripheral cannot know what the effective throughput is, this depends on all of the external variables they have no control over (CPU speed, adapter type, driver, OS, SCSI bus implementation,...). You can figure out the continous data rate yourself, by looking at the clock rate the data is being transferred to/from the media. The continous data rate cannot be greater than the clock rate of the head. If the clock rate of the head is 10Mhz, the continous data rate over the SCSI bus will usually be about 900KB/sec. Best case would be 1MB/sec, but there is some overhead for setup on each byte, so it drops a bit. If this drive is clocking data at 10Mhz, you are getting a decent throughput, if not the best the drive can muster. Oh and one other thing. In SCSI, the terms BIG, FAST, and CHEAP are usually contridictions in terms. BIG and FAST are okay, but the third qualification usually waters down the other two. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
garyb@SSD.CSD.HARRIS.COM (Gary Barton) (05/19/91)
In article <283400113@adaptx1> neese@adaptx1.UUCP writes: >... >You can figure out the continous data rate yourself, by looking at the clock >rate the data is being transferred to/from the media. The continous data >rate cannot be greater than the clock rate of the head. If the clock rate >of the head is 10Mhz, the continous data rate over the SCSI bus will usually >... There is a much easier way to figure out what the approximate sustainable transfer rate of a disk drive is, but you have to know something about the geometry of the disk drive. An upper bound on the sustainable transfer rate of any disk drive is given by T: RPM T (bytes/sec) = --- tracks/sec * N Sectors/track * M bytes/Sector 60 So if the drive manual does not describe the sustained transfer rate of the drive, but does specify the rotational rate, number of tracks per sector, and sector size, the sustained transfer rate can be derived. This assumes that the imbedded SCSI interface can maintain at least this rate. If it cannot, calculating the sustainable rate is much more complicated because you now have have to account for an extra rotational latency every time the disk heads get more than the drives internal buffer size ahead of the SCSI interface. Ggenerally speaking, most disk drive vendors supply embedded SCSI controllers that can keep up with the media (at least using SCSI synchronous transfers), so the computation above is usually a good approximation. Of course drives that have variable geometries will have variable sustained transfer rates depending on where you happen to be transferring to/from on the disk. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Gary Barton | System Software Development | | Lead Engineer | Harris Computer Systems Division | | garyb@hcx1.csd.ssd.harris.com | 2101 W. Cypress Creek Rd. | | gbarton@ssd.harris.com | Ft. Lauderdale. FL 33309 | | uunet!hcx1!garyb | (305) 974-1700 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jeremy@perf2.asd.sgi.com (Jeremy Higdon) (05/21/91)
In article <3415@travis.csd.harris.com>, garyb@SSD.CSD.HARRIS.COM (Gary Barton) writes: > > There is a much easier way to figure out what the approximate > sustainable transfer rate of a disk drive is, but you have to know > something about the geometry of the disk drive. An upper bound on the > sustainable transfer rate of any disk drive is given by T: > > RPM > T (bytes/sec) = --- tracks/sec * N Sectors/track * M bytes/Sector > 60 > > So if the drive manual does not describe the sustained transfer rate > of the drive, but does specify the rotational rate, number of tracks > per sector, and sector size, the sustained transfer rate can be > derived. This assumes that the imbedded SCSI interface can maintain > at least this rate. If it cannot, calculating the sustainable rate is > much more complicated because you now have have to account for an > extra rotational latency every time the disk heads get more than the > drives internal buffer size ahead of the SCSI interface. Ggenerally > speaking, most disk drive vendors supply embedded SCSI controllers > that can keep up with the media (at least using SCSI synchronous > transfers), so the computation above is usually a good approximation. Two other things that will affect throughput for large transfers are head switch time, and single track seek time. I've seen quite a difference between two drives that have 85 sectors per track and spin at 3600 RPM (2.2 vs 2.55 MB/s). If the vendor gives only the raw media transfer rate, you also have to know about format efficiency. Again, I've seen two 24mhz drives at 3600 rpm, that differed by 5% (81 vs. 85 sectors per track).