[Info-vax] The Future of Server Hardware?

[Johnny Billquist]

On 2012-10-03 21:18, glen herrmannsfeldt wrote:
> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> As for your current preferred focus on disk storage, reading a
>> rotating-rust disk is inherently glacially slow.  Writing is glacial,
>> too.  I don't know the instruction-comparison count off-hand, but it
>> wouldn't surprise me to hear it was on the order of a million
>> instructions worth of time to get a sector read from rust and into main
>> memory, or longer.
>
> For many years, 3600 RPM disks have been common, so 8.33ms average
> rotational delay. For servers, now, 7200RPM might be more usual,
> ro 4.16ms. A million instructions doesn't sound far off.

3600 rpm? I didn't even know you could find that anymore. I thought the 
standard for any cheap home PC was 7200 RPM. For people who really care 
about performance, and have money, 15.000 RPM is common, and I think you 
can also find 18.000 RPM. However, I guess that market is now going for 
SSD instead.

But since CPUs are screaming fast, I'm pretty sure 1 million 
instructions are probably still true.
Also, don't forget that rotational latency is just part of the equation. 
You also have head movement times, which traditionally have been the 
major part of time spent in a seek.

3600 RPM, by the way... That is the rotational speed of the RM03 (or was 
it just 3000 RPM?). Also the RP04/05/06 if I remember right. Really old 
disks... Sounds unlikely that todays small disks wouldn't spin any 
faster than that.

>> Cray had a clever system for rolling in from glacial rotating-rust
>> storage, an eon ago.  The CPU detected the location of the disk heads,
>> did the math to figure out where that sector should be in main memory,
>> and striped the contents of the disk into memory from the current disk
>> head location.  This in place of reading the sectors of rotating-rust
>> sequentially, with all the glacial disk head seeks and the glacial
>> waits as the disks spun the target sectors around under the heads that
>> was entailed.  It wouldn't surprise me to find this algorithm used in
>> other boxes.
>
> I believe that many current disks do this internally. When asked
> to read a sector, seek to the appropriate track, then start reading
> into cache. When you read the needed sector, return it, then finish
> reading the track. When requests come in for nearby sectors, they
> are already in the cache.

Yes. Disks do this internally, just as the intelligent controllers do it 
internally. And in addition, they optimize requests to minimize head 
movement. This was all done already in the 80s.

It's many layer of caches...

	Johnny