[comp.unix.i386] rotational latency

rcd@ico.isc.com (Dick Dunn) (05/03/90)

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
[somebody else said...]
>     What is this? Different drives have DIFFERENT
>     speeds. Even the same supplier does NOT adhere to the same speeds. 
> 
> Bah. Virtually every drive around does 3600 RPM,...

This is true nowadays, on PC-class drives, but...

>...This value of 3600 RPM has been constant for the past 30 years. from
> mainframes to micros, and for good (e.g. mechanical) cause...

Foo, not a chance.  It's gotten more constant as time has gone by, but in
the past it was a lot more common to see slower drives.  The RK05 and RL01,
among other unfortunately common drives, were both in the low-to-mid
2000's.  The slowest drive I recall was 960 rpm (and alas, rotational
latency was not the limiting factor).

In fact, the trend has been *toward* 3600 rpm as a standard in the past
decade or so, for causes as much electromagnetic as mechanical:  You're not
just interested in latency; you care about capacity.  If you want to
increase the rotational speed without losing capacity, you have to increase
the linear recording density.  As recording technology has improved (better
coatings, plated media, thin-film heads, vertical recording) the bit
densities have gone up and the drives have gotten smaller, with the
rotation speed tending to become a constant.

In the past there have been very strong constraints on the transfer rate
systems could handle.  The old IBM mainframe 1.5 Mb/s channel limit held
for what seemed like ages relative to speed improvements in the other
parts of systems.

>...There have
> been steady improvements in seek times and bandwidth, and rotational
> latency is thus becoming the bottleneck...

Yes, but this has happened relatively slowly.  CPU speeds double every
year; seek times might be halved every ten years.  We're finally getting
down to where the rotational latency is obnoxious enough that there's an
incentive to spin faster.  But it's not getting as bad as you might think
as fast as you might think.  Rotational latency is most obnoxious on track
switch and single-cylinder seeks, but you can compensate reasonably by
sensible allocation and skewing.  Track-caching controllers help too.

>...Palliatives revolve around the
> multiple arm idea, i.e.  reinventing drums, e.g. disc arrays (introduced
> to the 386 world by compaq or zenith recently)...

Multiple arms have been around for a while in the mainframe world, but
don't expect to see them in this part of the world for quite a while.
They're bulkier, require more peak power, are more expensive to build (you
need two of not just actuator but all the servo and r/w systems), and are
electromechanically tricky because one actuator can bounce the other one
around.  Even with all that, they only reduce rotational latency by a
factor of two and it's not practical to "multiply" that factor by re-
applying the technique.

Digressing a bit:  When you start predicting what's going to change and by
how much, you have to keep power consumption in mind.  Faster seek times
are difficult, and have come very slowly, because there's a power issue
involved.  You're accelerating the head/arm assembly.  If you want it to
move faster, you have to make it lighter or push it harder.  If you make it
lighter, it has to become stronger at the same time, to withstand greater
acceleration.  If you push it harder, you have to be able to supply the
power.  (It's an interesting exercise to calculate the power required;
it's straightforward F=ma and conversion-factors stuff once you know the
mass you have to move.)  You also have to be able to dissipate the heat
from the energy used in seeking.  The combination of smaller form factors
and tighter cabinets means this is getting harder.  All of this adds up to
a statement that seek times are still only improving gradually; don't plan
on radical improvements in the conventional style of disk drive.

The usual approach to disk arrays doesn't help rotational latency:  The
data you want starts somewhere, so you have to wait for it to come around
on whatever disk it's on.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Lately it occurs to me what a long, strange trip it's been.