Re: Questions comparing 1394 and Ethernet [was Re: Recommended 1394 chipsets?]

On Sat, 2004-06-05 at 12:29, Alan Shieh wrote:
> Steve Kinneberg wrote:
>
> >The eth1394 driver has been clocked at 135 Mbps on a 400 Mbps link.
> >Definitely room for improvement, but still, not bad. Can't say what the
> >CPU utilization was.
> >
> >
> That's a little disappointing for the toy application that I'm
> targetting. I think I can beat that by adding 1 or 2 100Mb cardbus NICs
> + using a combination of md, nbd, and VLAN tricks, probably with better
> stability, too.

Yes, bonding 2 100 Mbps cards will yield better IP networking
performance. That and most of the NIC drivers for Linux have had better
testing. We use IP over 1394 for communicating between embedded devices
at work, but our bandwidth needs are relatively modest.

>
> Do you have any more details about the benchmark? E.g., does the
> transfer include disk overheads?

The 135 Mbps number is from transferring an uncompressed Linux kernel
source tarball (approx. 130 MB) via FTP. So, yes disk access was
involved, but it was to an internal IDE drive, not a FireWire drive.

> Also, do you know the ballpark figure
> for SCSI transfers? (preferably measured host to host, rather than host
> to IDE bridge). If the SCSI transfer rate is reasonable, I would feel
> better about getting into 1394.

Can't answer anything about the performance of the SCSI layer or SBP-2.

>
> That brings up another question. I'm in networking, so most of my
> detailed hardware knowledge stops at the Ethernet NIC level.
> In a typical 1394 hardware/software stack, how much acceleration does
> the SCSI layer get? For instance, a plain Ethernet NIC (i.e. no RDMA or
> TCP offload magic) will blindly DMA incoming packets into the descriptor
> ring, without any sort of intelligent parsing. This can complicate
> zero-copy design. Does OHCI (please correct me if I have my layers
> messed up, as I'm not up to speed on the 1394 lingo) provide nicer DMA
> features? E.g., is the hardware smart enough to match a SCSI reply
> directly to the intended buffer?

I don't think that SCSI replies will ever get matched directly to the
inteded buffer by the hardware. The base 1394 protocol has absolutely
no knowledge of SCSI anything. SBP-2 is solely responsible for SCSI <->
1394 translation. In effect, SBP-2 tunnels SCSI transactions through
the 1394 link.

To give you an idea how FireWire relates to other protocols that use it,
consider the following.

In a normal SCSI setup, you have the block layer sitting on top of the
SCSI protocol layer, which in turn sits on top of the SCSI hardware
driver which talks to the real SCSI device.

In a FireWire environment, the SBP-2 protocol driver takes the place of
the SCSI hardware level driver and sits on top of the core IEEE 1394
driver. The core IEEE 1394 driver then sits on top of the hardware
level driver (in this case the OHCI driver).

The same goes for the eth1394 driver. It takes the place of a NIC
driver and sits on top of the core IEEE 1394 driver.

-- 
Steve Kinneberg
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user