[9fans] Re: etherelnk3.c

[G. David Butler gdb@dbSystems.com]

>>Of course the current support in the fs is for pretty slow
>>scsi controllers, from what I've seen.  One could stick a 
>>PCI controller that looks like an AHA1542 in there but the 
>>driver wouldn't utilize 32-bit addressing, forcing the use of
>>bounce buffers...  hmm, didn't some of the VLB cards have 
>>a larger address space?
>
>this has been gone over before on the list. given the buslogic eisa controller
>driver in the fs kernel (which is no slouch), it's trivial to make a buslogic pci
>controller work in 32-bit mode; that's what we use.

Well, a little work on the 154x, with multiple outstanding requests
per target, scatter/gather to 32k of queued operations, buson
time of 15 and busoff time of 0, is no slouch either; especially
with 4 controllers in a system with 4-6 targets each.  [This is
why I need a 3c515 busmaster ethernet card with 64k of RAM. :-)]

I also did a 1740x enhanced driver on the EISA bus to determine
how bad the ISA bus is.  I have the 154x on the ISA bus writing
a little less than 2MB/sec to the drives.  The 174x can do almost
4MB/sec.  (The 174x in standard mode also does about 4MB/sec,
bounce buffers notwithstanding.) I've seen a 294x (on *NIX) do
5MB/sec.  [Of course you really pay for it with the 2940.  During
that 5MB test 47% of a P5/133 was eaten up!  A test on the same
system with a 154x got 1MB/sec but used only 4% of the CPU.  The
154x is a very sweet design.]

In any case, random I/O cuts the rate per target to *much* less,
perhaps a couple hundred K/sec.  In this case allowing outstanding
commands, scatter/gather and disconnect make all the difference.

When PCI finally settles down and gets as reliable as 154x's on
the ISA bus, I'll move.  Of course a good SCSI adapter design
would be nice.  I hate the 294x.  Does anybody have any experience
with the Qlogic board?  (http://www.qlc.com)  It looks like
a good alternative.

One note, the code in the 154x driver says that the card does
not guarantee the order of SCSI operations which is why the
driver allows only one RBUFSIZE scsi command at a time.  This
is so true.  If you allow the SCSI subsystem to be more
asynchronous, expect the writes to be out of order and you
have to do something to keep a crash and running "check" from
eating your lunch.  Remember, fsck on *NIX only works if the
freelist and inode updates are well ordered.  Plan9 is not
any different.

David Butler
gdb@dbSystems.com