Newsgroups: comp.sys.ibm.pc.hardware
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!kessner!david
From: david@kessner.denver.co.us (David Kessner)
Subject: Re: Unix on 486 Machines
Message-ID: <1991Jun11.062033.5218@kessner.denver.co.us>
Organization: Kessner, Inc.
References: <9106110417.AA06408@w20-575-117.MIT.EDU>
Date: Tue, 11 Jun 91 06:20:33 GMT

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.

Ah, no.

Several points I'd like to make.

The "test" PG Mag did a while back only tested the busses with MS-DOS!  In
fact, it was mentioned in an editorial in that same issue that they planned
to have another issue comparing ISA/EISA/MCA under more favorable conditions
like UNIX and Novell-386, etc.  Well, as you and I know, they never had that
issue.  In that same editorial, it was mentioned that they expected EISA/MCA
to perform much better than ISA under UNIX.

Testing any high-performance hardware (CPU, Hard drives, busses, etc) under
MS-DOS is stupid.  MS-DOS is more of a bottleneck than the hardware is.

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).  

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.

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.  

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.  

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.

-- 
David Kessner - david@kessner.denver.co.us            |
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) | Reunite PANGEA!
Compuserve?  Isn't that some sort of FIDO BBS?        |
