Hi Tom,
Yes, there is a goal in mind, and definetly not performance : we are
working on device failover, i.e when a network adapter or switch fails,
use the remaining one. We don't intend to improve performance with
multi-rail (which as you said, will not happen unless you have a DDR card
wit
Ralph,
Sorry for answering on this old thread, but it seems that my answer was
blocked in the "postponed" folder.
About the if-then, I thought it was 1 cycle. I mean, if you don't break
the pipeline, i.e. use likely() or builtin_expect() or something like that
to be sure that the compiler wi
I believe the concern here was that we aren't entirely sure just where
you plan to do this. If we are talking about reporting errors, then
there is less concern about adding cycles. For example, we already
check to see if the IB driver has exceeded the limit on retries -
adding more logic t
What : when nothing has been received for a very long time - e.g. 5
minutes, stop busy polling in opal_progress and switch to a usleep-based
one.
Why : when we have long waits, and especially when an application is
deadlock'ed, detecting it is not easy and a lot of power is wasted until
the e
On 6/8/09, Sylvain Jeaugey wrote:
> Hi Tom,
>
> Yes, there is a goal in mind, and definetly not performance : we are
> working on device failover, i.e when a network adapter or switch fails,
> use the remaining one. We don't intend to improve performance with
> multi-rail (which as you said, will
I'm not entirely convinced this actually achieves your goals, but I
can see some potential benefits. I'm also not sure that power
consumption is that big of an issue that MPI needs to begin chasing
"power saver" modes of operation, but that can be a separate debate
some day.
I'm assuming