fur@ai.mit.edu (Scott Furman) (04/17/91)
I have seen a lot of info posted in this group about SCSI transfer rates. However, I have not seen as many postings about other performance parameters of SCSI drives. Recently I was reading some SCSI spec sheets for the Wren IV. A few parameters caught my eye: 1) Overhead time for head switch (512 byte sectors): < 2 ms 2) Overhead time for one-track cyclinder switch : 6 ms typical 3) Average rotational latency : 8.3 ms Two milliseconds to switch heads!? I would have guessed that switching sense heads was was done purely by electrical means. The overhead time for a track change also seems excessive. Apparently these overhead times are due to the use of embedded servo mechanisms which are commonly found now in modern drives. Embedded servos, I am told, increase reliability and reduce the price per byte. Does anyone have an explanation of why embedded servo are more reliable? Must these changes take place at the expense of performance? Are embedded servos particularly entrenched in the SCSI world where price/byte is a strong market force? Are there any manufacturers who make make drives that don't suffer these sorts of performance hits? The 8.3 ms average rotational latency is a result of the standard 3600 RPM. No surprises there. However, I understand Micropolis and HP have introduced drives that operate at 5400 RPM and 4000 RPM respectively. Has anyone used these? Are any manufacturers coming out with even faster ones? -Scott
rlr@alumni.colorado.edu (Roger Rose) (04/18/91)
In article <14971@life.ai.mit.edu> fur@ai.mit.edu (Scott Furman) writes: > Does anyone have an explanation of why embedded servo are more reliable? Better worded that embedded servo "may" be more reliable. The answer here is mainly because the servo information is closer to the data. The real answers ought to come from the servo gods, but I'll do my best here. Non-embedded servo dedicates a separate head to servo. The servo pattern is separated from the actual data. Quite possibly, the servo isn't even on the same platter as the data. This runs into problems due to uneven heat expansion within the drives and wear on the actuator. Embedded servo mixes servo and data onto the track. This way, you can position with the same head that is reading the data. This opens up another reliability problem, the head has write current connected and can accidently destroy the servo information. This is more severe than nuking sector headers. On extremely high-density drives, loss of servo means returning the HDA to the factory or replacing it, since the standard mechanics cannot position accurately enough to write servo. (Of course, there are interlocks to prevent overwriting servo, but active components aren't nearly as reliable as simply grounding the wire during assembly.) > Must these changes take place at the expense of performance? I don't know about "must", but I've not personally worked with a system where it didn't. One obvious hit with embedded servo is it isn't always there when you want it. You have to wait for it to come under the head, just the same as you wait on a sector. Servo is generally replicated around the track to minimize delay, but it's still slower than dedicating entire tracks to servo data. Another issue involves how often you need to look for servo. With dedicated servo tracks, you only need to look for servo when you switch to a new servo track. (Typically, this is on cylinder switches, but some drives have multiple servo tracks per cylinder to improve positioning.) Embedded servo may appear on every track; therefor, a track switch involves relocking the servo. -- Roger Rose {rlr@boulder.colorado.edu}
scott@labtam.labtam.oz (Scott Colwell) (04/18/91)
In article <14971@life.ai.mit.edu>, fur@ai.mit.edu (Scott Furman) writes: > I have seen a lot of info posted in this group about SCSI transfer rates. > However, I have not seen as many postings about other performance parameters of > SCSI drives. > > Recently I was reading some SCSI spec sheets for the Wren IV. A few parameters > caught my eye: > > 1) Overhead time for head switch (512 byte sectors): < 2 ms > 2) Overhead time for one-track cyclinder switch : 6 ms typical > 3) Average rotational latency : 8.3 ms > > Two milliseconds to switch heads!? CDC/Imprimis/Seagate normally quote times _including_ controller overhead. Considering that at best it will be an 80188 on the drive interpreting the SCSI command, these are good figures. If you weren't using SCSI the equivalent function must be done on either the controller card or the host so you don't win either way (unless you have a fast host with a very dumb controller card.) The Wren V product spec quotes the head change overhead for a transfer that crosses onto another surface at 500us. The controller overhead is usually of the order of ~1ms for the CDC drives. Scott Colwell p.s. Wren drives use a servo track, not embedded servo.
sph@logitek.co.uk (Stephen Hope) (04/18/91)
fur@ai.mit.edu (Scott Furman) writes: >I have seen a lot of info posted in this group about SCSI transfer rates. >However, I have not seen as many postings about other performance parameters of >SCSI drives. >Recently I was reading some SCSI spec sheets for the Wren IV. A few parameters >caught my eye: >1) Overhead time for head switch (512 byte sectors): < 2 ms >2) Overhead time for one-track cyclinder switch : 6 ms typical >3) Average rotational latency : 8.3 ms >Two milliseconds to switch heads!? I would have guessed that switching sense >heads was was done purely by electrical means. The overhead time for a track >change also seems excessive. Apparently these overhead times are due to the use >of embedded servo mechanisms which are commonly found now in modern drives. >Embedded servos, I am told, increase reliability and reduce the price per byte. >Does anyone have an explanation of why embedded servo are more reliable? Embedded servo means that the drive uses positioning info for track following embedded in the track data. This is superior to a separate servo surface, since head or spindle misalignment or thermal effects cannot cause positioning errors. This in turn allows tracks to be closer together, increasing drive capacity. <Stuff Deleted> >-Scott Stephen Hope #include <std.disclaimer>
Rob_Steven_Kramarz@cup.portal.com (04/19/91)
We have tested a great many SCSI models during the process of certifying our disk array software for UNIX systems. (My firm, 1776, Inc. develops disk mirroring and disk array software running on standard SCSI drives.) We have unfortunately found that there is no way to predict how fast or slow a given drive will be from the specifications. There are several hidden factors that affect performance other than access time, including the efficiency of the electronics in getting on and off the SCSI bus, and how many retries are necessary due to SCSI errors. As a result, we have found expensive drives that are fast and cheap drives that are slow. One factor that is essential now is support for synchronous transfers which can make a huge difference in speed with the appropriate host adapter. In all honesty, I must say the device driver used makes a large difference too. We have found differences of an order of magnitude between drivers with buffering technology (such as ours) and the simple drivers which are usually shipped with the o.s. Disk striping can double or triple performance further. Rob Kramarz
dtb@adpplz.UUCP (Tom Beach) (04/19/91)
In article <1991Apr17.232548.24776@colorado.edu>, rlr@alumni.colorado.edu (Roger Rose) writes: > In article <14971@life.ai.mit.edu> fur@ai.mit.edu (Scott Furman) writes: > > Does anyone have an explanation of why embedded servo are more reliable? > Stuff deleted > > Non-embedded servo dedicates a separate head to servo. The servo > pattern is separated from the actual data. Quite possibly, the servo > isn't even on the same platter as the data. This runs into problems In MOST cases the servo is not on the same platter as the data. There can be only one data surface on the same platter as the servo. All other platters have 2 data surfaces. Hence (platters X 2) - 1 datasurfaces, 1 servo surface. > due to uneven heat expansion within the drives and wear on the actuator. Platters and actuators in the middle of the stack get warmer than those top and bottom. The servo tends to be on the bottom. Track densities today run > 1600 tracks/in. > > > > Must these changes take place at the expense of performance? > > there when you want it. You have to wait for it to come under the head, > just the same as you wait on a sector. Servo is generally replicated > around the track to minimize delay, but it's still slower than dedicating > entire tracks to servo data. It's often between ALL sectors. This has a side effect of lowering the sustained data rate with the same raw data rate. > Another issue involves how often you need to look for servo. With > dedicated servo tracks, you only need to look for servo when you switch > to a new servo track. (Typically, this is on cylinder switches, but > some drives have multiple servo tracks per cylinder to improve positioning.) > Embedded servo may appear on every track; therefore, a track switch involves > relocking the servo. An interesting point. I've not seen a performance degradation here but I haven't looked for it either. I think I will... Thanks! Tom Beach ------------------------------------------------------------------------ | Tom Beach : Sr Project Engineer : Mass Storage Technology | | phone : (503) 294-1541 | | email : uunet : dtb@adpplz.uucp | | ADP Dealer Services, ADP Plaza, 2525 S.W. 1st Ave, Portland OR, 97201 | ------------------------------------------------------------------------
wicklund@intellistor.com (Tom Wicklund) (04/19/91)
In <14971@life.ai.mit.edu> fur@ai.mit.edu (Scott Furman) writes: >Recently I was reading some SCSI spec sheets for the Wren IV. A few parameters >caught my eye: >1) Overhead time for head switch (512 byte sectors): < 2 ms >2) Overhead time for one-track cyclinder switch : 6 ms typical >3) Average rotational latency : 8.3 ms >Two milliseconds to switch heads!? I would have guessed that switching sense >heads was was done purely by electrical means. The overhead time for a track >change also seems excessive. Apparently these overhead times are due to the use >of embedded servo mechanisms which are commonly found now in modern drives. >Embedded servos, I am told, increase reliability and reduce the price per byte. >Does anyone have an explanation of why embedded servo are more reliable? >Must these changes take place at the expense of performance? Are embedded servos >particularly entrenched in the SCSI world where price/byte is a strong market >force? Are there any manufacturers who make make drives that don't suffer >these sorts of performance hits? Embedded servos are not SCSI specific. There are versions of ESDI, SMD, ATA, and other drive types implementing embedded servos. Embedded servos allow higher disk density. As the number of tracks per inch increases, it's not possible to keep the heads aligned exactly (temperature variations cause each arm to expand a different amount). So a single servo won't keep the heads aligned exactly enough. The solution is servo data on each platter. There are a few ways to implement this: 1. Embedded servo on each drive. Servo information is recorded on each surface on each track. 2. Periodic thermal calibration. A special area on each surface is reserved and contains servo data. The drive periodically (every few minutes to every few hours) performs a calibration operation, checking the relative positions of the heads. When a head switch occurs, it adjusts the head position to align the head precisely. 3. Some drive manufacturers have wanted to try method #2 but seek to an average of all head positions (so that head switches remain electrical only) but this method will not work as densities continue to increase. In summary, you can avoid the head switch time but at the expense of smaller drive capacity. >The 8.3 ms average rotational latency is a result of the standard 3600 RPM. No >surprises there. However, I understand Micropolis and HP have introduced drives >that operate at 5400 RPM and 4000 RPM respectively. Has anyone used these? Are >any manufacturers coming out with even faster ones? A number of manufacturers are moving to faster rotation rates. I believe IBM and Fujitsu have or will soon announce drives which spin at 5400 RPM.
taylor@intellistor.com (Dick Taylor) (04/19/91)
In article <14971@life.ai.mit.edu> fur@ai.mit.edu (Scott Furman) writes: > >Recently I was reading some SCSI spec sheets for the Wren IV. A few parameters Remember, the Wren IV is an OLD drive (designed before CDC MPI became Imprimis which became Seagate). I remember first seeing one some four or five years ago, which makes it antique in the 5.25" world. >caught my eye: > >1) Overhead time for head switch (512 byte sectors): < 2 ms >2) Overhead time for one-track cyclinder switch : 6 ms typical >3) Average rotational latency : 8.3 ms > >Two milliseconds to switch heads!? I would have guessed that switching sense >heads was was done purely by electrical means. The overhead time for a track >change also seems excessive. Apparently these overhead times are due to the use >of embedded servo mechanisms which are commonly found now in modern drives. >Embedded servos, I am told, increase reliability and reduce the price per byte. Actually, a lot of companies don't use embedded servos because they're slower and the reliability advantages are debatable. (And they make reformatting at different sector sizes impossible, which is a real competitive disadvantage). >... >force? Are there any manufacturers who make make drives that don't suffer >these sorts of performance hits? Lots of them. Including Seagate. You need to find some more modern drives to look at. > >The 8.3 ms average rotational latency is a result of the standard 3600 RPM. No >surprises there. However, I understand Micropolis and HP have introduced drives >that operate at 5400 RPM and 4000 RPM respectively. Has anyone used these? Are >any manufacturers coming out with even faster ones? > I don't know personally of any rotating at over 5400. Greater-than-3600 is becoming pretty common. >-Scott -- Dick Taylor