Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!tom
From: tom@stl.stc.co.uk (Tom Thomson)
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <4032@stl.stc.co.uk>
Date: 13 Feb 91 20:38:27 GMT
References: <1652@hpwala.wal.hp.com> <409@bria> <13252@lanl.gov> <1991Feb4.154607.8606@ux1.cso.uiuc.edu> <1991Feb4.210853.22139@odin.corp.sgi.com>
Sender: news@stl.stc.co.uk
Organization: ICL , Wenlock Way, Manchester M12 5DR, UK
Lines: 38
Reply-To:tom@nw.stl.stc.co.uk

>Async i/o wins when the disk has very long seek time and slow transfer 
>rates.  And it has to be slower than SCSI in order to win.  All IMHO,
>of course.
>
>*
>*JG has a several good points made. I can't be sure that the thing I explained
>*above is EXACTLY what he wanted, but I'll bet it will satisfy him as an
>*example.
>*
>
>Oh, its what he was talking about all right, it just doesn't make sense to
>do it on the kind of disks and controllers we use today.
>

Here we have Archer Sully demonstrating yet again that the JGs and Rubins of
this world are absolutely correct when they claim the "standard Unix or
nothing" brigade have nothing to offer to us on software architecture.  Mr 
Sully wants to put synchronous IO in my way, ie conceal from me the fact that
the hardware allows IO and processing to procede in parallel; he claims that
with today's discs it isn't needed.  I suggest he goes and tells that to all
the independent database vendors who spend so much effort in getting round this
particular piece of Unix stupidity in their Unix ports. Perhaps he can afford
for the machine to sit idle for 10 ms every time he moves the disc heads - he
maybe has never been involved in a time-critical or performance-critical
application. Or maybe he has some discs I haven't heard about yet - with
seek and head settle time plus half a revolution coming out way below 10 ms?
Or maybe he thinks the level of multiprogramming is so high that performance in
one process (elapsed time for one process) doesn't matter at all (in every
conceivable application)? Or maybe all IO is serial, so the OS can predict
where the next block will be and do the transfer in advance (I'd like to see 
it do that for writes, mind; would make data consistency a little difficult)?
In the real world, asynchronous disc io is a necessity. Fortunately IO hardware
design hasn't got as bad as processor design - - no-one is yet proposing to
stop the CPU running whenever an IO device has been asked to do a transfer
just because Unix (and Cobol, and a few more) impose that view on the poor
benighted user.

Tom Thomson