Jan mentions “under unspecified conditions” …
In both the QLogic and Broadband cards using the ISP family of chips, the
driver is responsible for loading the firmware into the cards NVRAM. To
write a driver for these cards you have to have that firmware, since it
vaporizes with power down. Broadband has an NDA with QLogic and we develop a
lot of our own firmware to do what we do. The NT/2000/XP drivers that I
provide wrap a proprietary fibre channel API that includes that firmware.
As to the pipelining that Jan talked about, the ISP 2x00 family can handle
multiple simultaneous transfer commands. Our proprietary API and firmware
allows the ISP chip to handle up to 64 commands, each with it’s own
scatter/gather list of up, to but no more than, 4096 descriptors… I’m not
sure what QLogic allows, but remember, their solution is directed more at
SCSI and IP where as we target customers that want large blocks of data
transmitted quickly without the overhead of ScsiPort.
Kristian, you will need to provide that firmware, as well as the low level
IO code that controls the board. To do this yourself, you really really need
to answer Jan’s question: “. Is there some reason you want to do large
amounts of development?” You can acquire an API from either QLogic or from
Broadband. Broadband provides either completed drivers for NT/2000/XP, or a
platform independent API. There may be another source for such an API for
the ISP chips, but working for Broadband, I only know of our product.
What Jan called “under unspecified conditions” turns out to be almost 6
man-years of blood sweat and tears. Which anyone in this industry, doing
this kind of work, is intimately familiar.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Tuesday, July 24, 2001 3:53 AM
To: NT Developers Interest List
Cc: xxxxx@atia.com
Subject: [ntdev] Re: SCSI - Connecting two PCs with FC cards
I’ve tried QLogic’s IP driver and it seems to work fine, but unfortunately
the performance is to low.
I have not found any usefull information neither for VI over Fibre Channel
or Winsock Direct both mentioned by Mark.
That might be because it tries to use ethernet size transfers (about 1500
bytes). You need BIG transfers to get FC to go really fast. You also need
the destination buffer ready to pour data into when you send it.
If you sequentially transfer a block at 100 MBytes/sec at the source bus,
and 100 MBytes/sec across the FC, and 100 MBytes/sec at the destination
bus, that’s only 33 MBytes/sec. Everything must run in PARALLEL (i.e.
smaller blocks pipelined) at 100 MBytes/sec to get good performance. The
little latencies turn into big performance hits.
If you have a client/server interaction architecture, think about your
server response time too. Synchronously requesting a 64 kbyte transfer,
with a 1 millisecond response time will give you < 64 MBytes/sec (it would
be something like 1 / (request processing time + data transfer time) /
block size)… Realistically, the transport time for the request will take
time, even if it’s only few bytes. Most hardware does not have a linear
curve of processing time vs. transfer size. Good questions are: what is
your transfer block size (hopefully megabytes), what is the command
processing time of the FC hardware, and can you pipeline requests. I’d
strongly suggest you draw a little timeline for your data flow, and add up
how much time it takes each step. The hardware folks tend to only talk
about raw maximum transfer rates, and tend to ignore how the
hardware/software will interact with other subsystems. Also, heavily
loaded, multiple streams are very different than a single stream/client.
Understand YOUR problem, and ask the vendors for data that fit’s what YOU
need to do.
My understanding was the Winsock Direct stuff was supposed to be a low
latency peer-to-peer channel for clusters and such, and bypassed the TCP/IP
stack.
In a previous message, Gary said his company made cards+drivers that did
100+ MBytes/sec under some unspecified conditions. Is there some reason you
want to do large amounts of development?
Depending on the FC hardware design, you might need to know little to a lot
about FC. The command interface presented by the firmware may have little
to do with FC protocol formats (the Emulex card was like this), or the
hardware may just be a thinner layer between the FC wire and the PCI bus
interface (the HP Tachyon as I remember). Either way, a fast, high quality
driver is a LOT of work.
Perhaps you can explain more details about what you need to do?
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com