[9fans] DPT PM2041W observations

[G. David Butler gdb@dbSystems.com]

I ordered a PM2041W and it arrived Friday.  I started with
the dpt driver in the update on plan9.bell-labs.com, the driver
kit from DPT and source to the BSDi driver from DPT and modified
my 154x/174x driver to talk to the 2041.  I finished Saturday
afternoon and ran some performance tests.

The 2041 is about 10%-15% *slower* than the 154x!  My main test,
write performance, gets 1260K/s on the 2041 and 1440K/s on the
154x to a single drive.  During the test the BUSY and WRITE leds
are on *solid* and the DATA FROM HOST and IRQ lights were on but
very dim.  The light on the drive was on solid too, but that never
means much.  (BTW, my test is real world.  The write data is
generated by my logging subsystem to one of the drives.  I just
cd to a directory and copy files to it.)

The computer is a P5/66 EISA bus computer with Micropolis 4421
hard drives.  I used the cable that came with the DPT.  On this
same computer and disk with a 1740 in enhanced mode I can get
2680K/s write performance, so the computer and the drive don't
seem to be the problem.  The same drive connected to a 2940
on a P5/133 PCI machine running Linux(yuck) can write ~4000K/s!

So, what gives?  I read in this group that the Smartcache IV
ISA controller was timed 40% faster than the 2940.  With that
kind of endorsement, I had to give it a try.  I wonder what
stupid driver was used on the 2940?

The way my drvier works is a call to scsiio creates a scsi_queue
entry ordered by r/w, unit, lun, scsi block address with all the
data copied for any >16M buffering and calls the routine that
creates ccb's.  The ccb routine gathers multiple scsi_queue
elements into a scatter/gather list of no more than 32k and
queues it to the adapter.  It stops after 4 ccb's per target.
On interrupt I get the adapter status, target status and ccb
address from the status packet then acknowledge the interrupt.
I then wake up each process waiting on it's scsi_queue entry.
If there are no more active ccb's (in other words, I shouldn't
expect another interrupt, I then try to lanuch more ccb's before
I return from the interrupt routine.  Once a process is awake,
it gets the status that was saved and if all is well, it copies
any >16M data and returns to the calling routine.  It is very
fast and keeps the adapter very busy.

I understand that the ISA bus is the problem I'm running into.
I'm just trying to get to all of it.  In PIO mode, the ISA
bus should be good for ~2MB/s. (8Mhz, 16bit, 8 clocks/transfer.)
In DMA burst mode with 12us bus on time and 2us bus off time,
I would expect ~6MB/s. (Burst at 8MB/s 80% of the time.)
I'm only getting about ~2MB/s throughput to the drives, so is
the drive idle for some time?  I know the adapter can accept
multiple outstanding commands, can the drives?

If the answer to that is "yes, with Tag Queueing", then I
need some kind soul to help me get that to happen on the
DPT adapter.  (The 154x can't do that.)  None of the
documentation or source I have enable that feature.

Thanks for any help.

David Butler
gdb@dbSystems.com