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}
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 | ------------------------------------------------------------------------