Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Questions and Answers...



Mike,

I learn something new every time I get mail from the kind folks on this
list.  It takes a bit of time to read questions, re-define the issue(s) in
better/clearer terms, and then compose a decent response.

I want to thank you in particular for the quantity as well as the quality
of your responses.  We would be in much worse shape without them.

Thanks for the reply.  I got the Adaptec controller out of the trash and
I'm going to give it a whirl.  Once I get going, I'll probably buy a
decent card, maybe with the NCR based chipset you mentioned.

Chuck Young
GTE Internetworking

On Wed, 30 Dec 1998, Mike Bilow wrote:

> Date: Wed, 30 Dec 98 07:40:00 -0000
> From: Mike Bilow <mikebw at bilow.bilow.uu.ids.net>
> Reply-To: discuss at tarnhelm.blu.org
> To: discuss at tarnhelm.blu.org
> Subject: SCSI adapters and the ISA bus
> 
> 
> 
> Chuck Young wrote in a message to Mike Bilow:
> 
>  CY> With all this talk of scanners and SCSI cards, I was
>  CY> wondering... 
> 
>  CY> Will an Adaptec 1542 16-bit ISA SCSI card provide decent
>  CY> performance over an on-board/PCI EIDE system? I thought the
>  CY> ISA bus was pretty slow. I realize the question is vague and
>  CY> there are advancements made every day in chipsets.  For
>  CY> discussion, lets assume an average P-166 and comparable
>  CY> disks running under linux 2.0.36. 
> 
>  CY> Generally, is an ISA SCSI adapter any faster than the
>  CY> on-board EIDE I/O? 
> 
>  CY> Anyone?
> 
> This is a complicated question.  First, the bandwidth of the SCSI bus is not
> likely to be any faster than the bandwidth of the machine bus.  Standard
> synchronous SCSI runs the bus at 5 Mo/s (million operations per second).  Fast
> SCSI doubles this to 10 Mo/s, and Ultra SCSI doubles this again to 20 Mo/s. 
> Narrow SCSI has an 8-bit data path that transacts one byte per operation; Wide
> SCSI has a 16-bit data path that transacts two bytes per operation.  The raw
> bus throughput therefore is just a matter of multiplying, and an Ultra Wide bus
> has a maximum theoretical bandwidth of 40 MB/s.
> 
> The Adaptec AHA-154xCF -- let's assume you are talking about the C series --
> can do Fast Narrow, which only goes up to 10 MB/s.  Of course, this is a
> theoretical maximum, so acknowledgements and device latency are going to limit
> sustained throughput to maybe a tenth of that for a given device.  SCSI is at
> its best when used to manage multiple devices in parallel, and this is where
> the bus bandwidth over individual device bandwidth provides useful headroom.
> 
> While the ISA bus is itself clocked at only 8 MHz, this is usually not a
> significant limitation for an AHA-154xCF controller.
> 
> EIDE, on the other hand, is an asynchronous protocol which can shove data as
> fast as the device can take it, at least in theory, and a PCI EIDE controller
> has a theoretical bandwidth accessible to the limit of the PCI bus, or four
> bytes per operation at 33 Mo/s, which works out to 132 MB/s.
> 
> In practice, device throughput is usually the limiting factor, and the bus
> bandwidth is not reached.  SCSI hard drives have more sophisticated and
> intelligent electronics on-board, so they usually run with larger caches,
> better prefetch and queueing algorithms, higher rotational speeds, and
> integrated error handling.  IDE hard drives are usually built to optimize for
> cost, so they often are much slower than SCSI hard drives of similar capacity.
> 
> However, IDE also has a lot of limitations.  The devices sharing an IDE channel
> cannot be operated independently, and it is not possible to use the other while
> the first is still pending an operation.  With SCSI, commands can be queued to
> one device on the bus and then the bus remains free for other uses until the
> first device calls back to notify the controller of status.
> 
> IDE controllers, except for the new UltraDMA scheme (which has its own
> problems), require the full attention of the main CPU while pushing data back
> and forth, while SCSI controllers release the CPU for other tasks.  You will
> not see any difference on an operating system which cannot multiplex I/O, such
> as Windows 95, but this can be a huge penalty for IDE on Linux.  The AHA-154x
> series, which is one of the few ISA busmaster devices ever made, is an even
> bigger win relative to IDE on this issue.  This was a much greater concern when
> CPU capacity was more limited and the standard server might have been a 486
> running at 66 MHz; as raw CPU power increases, it becomes expendable.
> 
> The end result is that SCSI drives tend to be faster in terms of sustained data
> rate than IDE drives of comparable capacity.  Even if this is not true in the
> case of your particular situation, the ability of SCSI to offload tasks from
> the main system CPU usually more than compensates.
> 
> Finally, however, I have to ask why you would bother with an ISA SCSI
> controller in a PCI machine.  You can get pretty respectable PCI SCSI
> controllers reasonably well supported under Linux, such as those based on the
> NCR/Symbios 53c810 chipset, for about $50.  Whatever disadvantages such SCSI
> controllers may have, they are almost certainly going to be faster than an old
> ISA SCSI controller.
> 
> The real importance of all of these issues ultimately depends upon the uses you
> plan for your particular machine.
>  
> -- Mike
> 
> 
> ***
> Subcription/unsubscription/info requests: send e-mail with subject of
> "subscribe", "unsubscribe", or "info" to discuss-request at blu.org
> 

***
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to discuss-request at blu.org




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org