Re: TCP/IP over SCSI

Randy Scott (
Wed, 9 Apr 1997 16:43:00 -0500

In article <5igu00$> you wrote:
: > Max TCP bandwidth seems to be around 430 KB/sec. I may be missing
: > something but isnt that SLOWER than 10BASE-T???

Yeah, yeah.. that was the best we could do given the hardware and time
that we had..

: I think the project above was meant to be a proof of concept rather than
: a solution in itself. The 152x driver, as patched for target mode, uses
: PIO for the data phase.

The project was meant as both a proof of concept AND a solution.

The 152x (AIC-6360) manuals claim that unless you are using EISA DMA
transfers (?) programmed-IO is considerably faster (than ISA DMA).

: It is possible to do target mode on the aic7xxx series, but driver gurus
: have expressed doubts as to whether initiator and target mode sequencer
: code will both fit into onboard RAM. I will probably investigate this
: after the NCR driver is working.

Something neat to try would be something like Alan Cox suggested:

"Its way to clever for the job. If you want to do this
seriously get some NCR ultra scsi cards and rewrite the
script files so they do nothing but loop polling a ring
buffer of commands to send and filling in empty slots in
an RX ring buffer."

This, of course, would require a dedicated SCSI host adapter to use on
the network. You might not necessarily want disks on your SCSI-network
bus anyway (we had one disk on our bus during the development).

Side Node: having the disk on the bus, and having the disk being used by
one of the two machines helped in some ways with debugging. Instead of
the machine (the one using the disk) just locking up or getting stuck
in a tight wait loop, we would see SCSI errors (timeouts, bus resets,
etc.) when the machine attempted to use its disk.

: I also hope to improve the 152x driver, but I haven't got my programming

Good luck. I think the card sucks pretty bad. However, the modifications
we added could use TONS more error checking to make it more stable.
Currently, we don't handle errors during data transmission.

: manual from Adaptec yet. If someone wants to send me an am974, I'll look
: at that, too. I don't know much about the 974, but realistically, if

As far as I am concerned (not having worked with the drivers for any other
SCSI host adapters), the AM53C974 is a REALLY nice controller. Once you
figure out what the hell the data sheet is trying to say, the controller
almost does ALL of the work for you. It is a PCI Fast SCSI-II controller

: you're looking for fast data transfer, a bus mastering PCI card with an
: independent processor is the only way to go - preferably a family that
: will go to 40 or 80MB/s.

The key to getting fast transfers will probably lie in using synchronous
transfers. We didn't have the time to investigate this at all. Doing
this may be as easy as exchanging a couple of messages between target and
initiator and setting up the host adapters to work right.

Assuming there wasn't an over abundance of overhead involved in the
drivers (and assuming the 152x can handle it), we should have been able
to get a full 5Mb/s between our two machines.

One other side note: I forgot to put in the documentation the fact that
the driver MAY (havent tested it in a while) not work quite right when
it attempts to send to multiple SCSI IDs. Try not running "snconfig,"
so that the driver attempts to send to all available SCSI IDs on the bus.
We noticed that somewhere along the way (after it attempts to send it
to the first available ID, and before attempting to send to the last
availble ID), the data associated with the command gets destroyed (not
the command block itself). We were unable to trace this problem down
to any one point. A possible solution MIGHT be to memcpy() the data
into a newly allocated buffer for EACH transmission attempt. This is
obviously not a very good solution.

Ben Elliston <> is (or will be starting
shortly) writing an article for the Linux Journal about IP over SCSI.
He would probably be interested in any comments you have about the
project in general (as would I).

Randy Scott <>