FireWire

[Jim Lux]

-----Original Message-----
From: Mark Hahn <hahn at coffee.psychology.mcmaster.ca>
To: Jim Lux <James.P.Lux at jpl.nasa.gov>
Date: Wednesday, February 28, 2001 1:32 PM
Subject: Re: FireWire


>> 4) The basic programming model is shared memory spaces
>
>huh?  where does that come from?  I don't believe 1394 provides
>anything like SCI's support for shared memory.

The programming model (not the hardware) is shared memory.  To the
application writer, all the details of the 1394 interface are buried, and
you just write to what looks like shared memory.  Actually, the 1394
interface recognizes that you've written, stuff picks up the data, builds
the appropriate messages,  and shuffles it off to the eventual destination,
where the "reader" reads the "memory".  The message passing nature of the
actual physical interface is concealed from the applications writer.  And,
of course, there are all sorts of setup and hooks to provide interrupt
driven access (i.e. you can get an interrupt when the "receiving memory" has
been written to (presumably by some outside force...)"

Much like using a DMA based disk interface, you don't actually care how the
data gets to or from the disk.  You put the data out there, tell the
interface that it's there, and it goes to the disk.  In some 1394
implementations, you don't even have to do the "tell the interface it's
there" step.

It's a very clean simple model for applications programmers, and can have
very high performance (say you map that "shared memory" to a video
display....) so it's good for time to market, but makes the implementation
of a 1394 widget quite complex.  What would traditionally be in a software
driver is embedded in the 1394 controller ASIC.

>
>> 5) The way to use 1394 in a beowulf would be to write interface code to
the
>> 1394 directly from MPI or a similar package, and not to even fool with
TCP,
>> Sockets, etc.
>
>I don't get this either: sockets are very generic, and certainly
>are an appropriate user-level interface for 1394.  using TCP is a
>good idea whenever the interconnect is subject to packet loss,
>reordering, congestion, etc, since interfaces simpler than TCP
>are doomed to reinvent ways to handle those issues, poorly.

TCP has long headers, etc.  If you have a basically error free link (or one
where error control is done at a lower level), then there are all sorts of
protocols which would be better.

Not that sockets aren't a good generic interface, and easy to program to
from an applications sense, it's that they may not be the most efficient way
to use the 1394.  We speak here of getting the most comm performance out of
the link, not minimizing coding time, etc.   In general, the fewer layers of
virtualization between the high level abstraction and the physical hardware,
the faster it will be.

Think of zero copy implementations for ethernet vs standard one or two copy
implementations.

>
>