LAM uses the lamd RPI to create the LAM topology. After that, depend of
the configuration, the usysv RPI (my case) is used to transfer the data
between processes. am I correct?
You said that the RPIs daemons communicate with each other through UDP.
If the topology is stablished with TCP RPI, how the communication is?
they use both UDP and TCP? TCP for transfer data and UDP for signaling?
Would you like to tell me about the set of daemons that LAM uses? What are
they called?
Thanks
> On Tue, 1 Apr 2003 dburbano_at_[hidden] wrote:
>
>> I want to represent the LAM software architecture in a diagram,in my
>> research
>>
>> I read "Design of a VIA based communication protocol for LAM/MPI
>> Suite". This paper talks about 2 layers. The upper layer that
>> translates the MPI functions to vendor architectures and transport
>> protocols (This layer does not have name). And the lower layer that
>> implements the
>
> We actually typically refer to this upper layer as "the MPI layer",
> because it's mostly comprised of libmpi.a, and handles all the
> MPI-specific logic (managing requests, communicators, groups, etc.)
>
>> message protocols. They talk about a layer between these layers that
>> is called RPI. The TCP transport, usysv trasnport, and sysv trasnport
>> are in the lower layer. In the above paper separate the LAM daemon
>> "lamd" of usysv, sysv, tcp.
>
> Correct. If you didn't see it in the documents anywhere, RPI stands for
> "Request Progression Interface". What that name means is that the RPI's
> API is designed around the life of an MPI request. Hence, you'll see
> API calls for creating a request, starting a request, progressing a
> request, etc.
>
> I should note that there technically is one more layer -- the LAM layer.
> See below.
>
>> In the following documents: README, INSTALL, RELEASE_NOTES for LAM
>> 6.5.9 they talk about LAM software architecture too. They talk about
>> there is transport layer called RPI which contains different
>> communication methods depend on the hardware architecture (TCP
>> trasnport, usysv trasnport, sysv transport). I understand that the
>> RPI is located in the trasnport layer.
>
> I'd say that that is roughly correct -- the RPI is all about moving
> bytes from process A to process B.
>
>> they talk that there is a LAM daemon for each user, and this daemon
>> execute the communications in LAM.
>
> More or less. There is a set of LAM daemons for each user -- the stuff
> that you launch via lamboot. This collective set of daemons comprises
> the LAM run-time environment, which we typically call the LAM Universe.
> The MPI layer uses the services that are provided by the LAM layer.
> Hence the name "LAM/MPI".
>
> These daemons communicate with each other through UDP. The lamd RPI,
> actually, uses this daemon-to-daemon communication model -- all the
> other RPI's are direct client-to-client communications (and after
> initial setup, do not use the lamds for moving bytes from process A to
> process B).
>
>> The above documnets don't explain me the LAM software architecture. I
>> understand the following:
>>
>> LAM is conformed by 2 layers: The upper layer translates the MPI
>> functions to the lower layer(vendor architectures and transport
>> protocols). And the lower layer called RPI. This layer is configured
>> in installation time with the equivalent RPI (TCP transport, sysv
>> transport, usysv transport). The RPI is located in the transport
>> layer.
>
> The only thing I'd be fuzzy about there is "the RPI is located in the
> transport layer". Many people have many different defitions for the
> transport layer. All of LAM is user-level code -- so nothing is
> actually in the OS kernel itself. So it's not in the OS's transport
> layer. But I suppose you could consider it to be in LAM/MPI's transport
> layer.
>
>> And the LAM daemon use the configured RPI to execute the communication
>> with other LAM daemon.
>
> No. Unless you're using the lamd RPI, the LAM daemon (lamd) is not used
> for RPI communication.
>
>> The LAM software architecture is represented by:
>>
>> sesion layer -> MPI API
>> -------------------
>> upper layer (how it is called?)
>> -------------------
>> transport layer -> RPI layer (tcp, usysv, sysv)
>> -------------------
>> phisical layer -> Hardware
>
> I've attached an encapsulated postscript figure that we typically use in
> papers and whatnot. Note that there are actually 4 layers shown:
>
> - user application
> - MPI layer
> - LAM layer
> - operating system
> - ...you could list hardware here, too
>
> The MPI layer itself is what is split into multiple layers -- the "upper
> layer" which handles all the MPI logic and the RPI (which I would
> consider to be the "lower" layer of the MPI layer).
>
> In LAM 7.0, this definition gets a little fuzzy because we've gone to a
> modules-based architecture in which the RPI is only one of several
> different kinds of modules that constitute the MPI layer. But the RPI's
> role is still the same -- moving bytes from process A to process B for
> MPI's point-to-point communication.
>
> Does that help?
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
|
