Looks good. Thanks for the fix.
Cheers,
Josh
On Mar 31, 2008, at 1:43 PM, Ralph H Castain wrote:
Okay - fixed with r18040
Thanks
Ralph
On 3/31/08 11:01 AM, "Josh Hursey" wrote:
On Mar 31, 2008, at 12:57 PM, Ralph H Castain wrote:
On 3/31/08 9:28 AM, "Josh Hursey" wrote:
At the mo
Okay - fixed with r18040
Thanks
Ralph
On 3/31/08 11:01 AM, "Josh Hursey" wrote:
>
> On Mar 31, 2008, at 12:57 PM, Ralph H Castain wrote:
>
>>
>>
>>
>> On 3/31/08 9:28 AM, "Josh Hursey" wrote:
>>
>>> At the moment I only use unity with C/R. Mostly because I have not
>>> verified that the
On Mar 31, 2008, at 12:57 PM, Ralph H Castain wrote:
On 3/31/08 9:28 AM, "Josh Hursey" wrote:
At the moment I only use unity with C/R. Mostly because I have not
verified that the other components work properly under the C/R
conditions. I can verify others, but that doesn't solve the probl
On 3/31/08 9:28 AM, "Josh Hursey" wrote:
> At the moment I only use unity with C/R. Mostly because I have not
> verified that the other components work properly under the C/R
> conditions. I can verify others, but that doesn't solve the problem
> with the unity component. :/
>
> It is not cri
At the moment I only use unity with C/R. Mostly because I have not
verified that the other components work properly under the C/R
conditions. I can verify others, but that doesn't solve the problem
with the unity component. :/
It is not critical that these jobs launch quickly, but that they
I figured out the issue - there is a simple and a hard way to fix this. So
before I do, let me see what makes sense.
The simple solution involves updating the daemons with contact info for the
procs so that they can send their collected modex info to the rank=0 proc.
This will measurably slow the
Ralph,
I've just noticed that it seems that the 'unity' routed component
seems to be broken when using more than one machine. I'm using Odin
and r18028 of the trunk, and have confirmed that this problem occurs
with SLURM and rsh. I think this break came in on Friday as that is
when some o
