This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On May 12, 2010, at 7:50 PM, Jeff Squyres wrote:
> On May 12, 2010, at 1:21 PM, Nils Carlson wrote:
>> Probably not me personally, my employer is considering financing a
>> masters thesis with the aim of doing an implementation.
>> Is there a guide for adding support? I took a quick look at the tcp
>> code, and it wasn't all that straightforward,
>> though I suppose a lot of the code is aimed at maximising
> There has been a paper or two written about this kind of stuff (like
> what David mentioned; and I have a dim recollection of someone else
> writing their about their experiences of adding a BTL). But nothing
> in the way of formal documentation, sorry. :-\
> I'd be happy to chat on the phone about it.
I will have to discuss this with my manager on monday, but there does
seem to be some potential here.
The background is that Ericsson (my employer) developed TIPC a few
years ago, and let it loose.
Our goal has been to get the community more involved with TIPC and
contributing support to OpenMPI
would perhaps be a good way forward. One thing that strongly
recommends TIPC (besides very high performance
and low latency) is that it can handle failover (to a backup network)
very gracefully (and transparently to the application),
something that MPI (at least when I last used it around 2007) did not.
It is also extremely simple to configure.
Using MPI on TIPC would also give us access to good benchmarking
possibilities, good for future protocol-stack improvements.
>> How long do you think a basic implementation would take?
> I don't know much about the TIPC API to say. Have a look at ompi/
> mca/btl/btl.h -- that's the set of interfaces that need to be
> implemented. They're mostly focused on connecting, disconnecting,
> and sending/receiving data.
> We do have a subsystem for monitoring fds for read and write events,
> so if TIPC is based on fd's, it could probably use our internal
> libevent to monitor for progress, etc.
TIPC uses a sockets API, plus some additional features and minus a few
non-applicable features, so it should be feasible.
> Jeff Squyres
> For corporate legal information go to:
> devel mailing list