From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 30 Dec 1997 21:51:43 -0600 From: G. David Butler gdb@dbSystems.com Subject: [9fans] Re: etherelnk3.c Topicbox-Message-UUID: 6f4df0f4-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19971231035143.tcfauWRb2qYqyZYOj37YweIWvT3o8TS0fEryrrGHnJ4@z> >>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