Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!mic!letni!rwsys!merch!cpe!adaptex!adaptx1!neese
From: neese@adaptx1.UUCP
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: Unix on 486 Machines
Message-ID: <284500029@adaptx1>
Date: 18 Jun 91 07:37:52 GMT
References: <6408@w20-575-117.MIT.EDU>
Lines: 64
Nf-ID: #R:w20-575-117.MIT.EDU:6408:adaptx1:284500029:000:3246
Nf-From: adaptx1.UUCP!neese    Jun 17 16:54:00 1991


>In article <9106110417.AA06408@w20-575-117.MIT.EDU> pshuang@ATHENA.MIT.EDU writes:
>>The bus does not seem to be as huge an issue as IBM would have
>>had you believe with their push for MicroChannel architecture, according
>>to PC Magazine tests about a year back, when they concluded that for
>>most setups and users and applications, ISA vs. EISA vs. MicroChannel
>>made little difference to real-world throughput.  In any case, ISA's
>>16-bit bottleneck applies only to I/O and does not affect the 32-bit
>>processing speed of the i486 CPU, unless you are supplying memory via a
>>expansion board on the bus, which would be plain silly.
>
>STUFF DELETED<
>Disk transfer rates for EISA is only about 10-20% faster than ISA (after all,
>you can only get the data off the disks so fast).  

True, for the most part.

>The REAL benifit of EISA comes into play when a multitasking system is being
>used.  When a UNIX task requests a block from the disk (on an ISA bus), the
>CPU goes off and grabs that block-- it takes 100% of the CPU time to get that
>block since the ISA bus and hard drive controllers are brain-dead.

Actually, if you use a bus master on the ISA bus, this makes what you just
stated untrue.  I'll get into more detail at the end.

>When an EISA based UNIX system requests a disk block, the OS tells the 
>controller to read a block into memory.  It then puts that task on hold
>(until the block is read in), meanwhile it goes off and runs another task.
>So, while the one task is waiting for the disk controller, others are still
>being executed-- where as an ISA based machine will pause all tasks since the
>CPU is tied up doing the disk transfer.  

If a bus master is used in either EISA or ISA based buses, they both get a
lot more free CPU time, but while the adapters/controllers are bus masters
the CPU is dead.  The gain comes from the speed the bus masters can move the
data to/from host memory.  Much faster than a PIO controller which requires
the CPU's full attention.  Thus with the bus master nmoving the data faster
the CPU can get back to work quicker which represents an overall gain in
throughput for the CPU.

>MS-DOS cannot take advantage of this, since MS-DOS is not multi-tasking.  In
>fact, things like Desqview and Windows also cannot do this, since they are
>built on MS-DOS's file system.  

The file system is irrelevant.  But the rest of what you say is quite true.
The reason they are single-threaded (Windows, Desqview) is due to the BIOS
restrictions.  In order to work with the hardware in a transparent manner,
these programs use the INT13 BIOS calls for disk stuff.  The INT13 BIOS is
a single-threaded non-re-entrant piece of code that must be run in real
mode.
The operating system itself is designed to be a synchronous operating system
where any read/write will be waited on before control is returned to the
application.

>Putting RAM on the EISA bus is silly, I agree.  The EISA bus, like other
>busses, should only be used for I/O.  I/O, however, is more important when
>you are using a 20 MIPS CPU.

As well as an OS that can take advantage of it.

			Roy Neese
			Adaptec Senior SCSI Applications Engineer
			UUCP @  neese@adaptex
				uunet!cs.utexas.edu!utacfd!merch!adaptex!neese