On 9/8/2010 8:09 AM, Brice Goglin wrote:
> Le 08/09/2010 14:02, Jeff Squyres a écrit :
>> On Sep 3, 2010, at 3:38 PM, George Bosilca wrote:
>>> However, going over the existing BTLs I can see that some BTLs do not correctly set this value:
>>> BTL Bandwidth Auto-detect Status
>>> Elan 2000 NO Correct
>>> GM 250 NO Doubtful
>>> MX 2000/10000 YES (Mbs) Correct (before the patch)
>>> OFUD 800 NO Doubtful
>>> OpenIB 2000/4000/8000 YES (Mbs) Correct (multiplied by the active_width)
>>> Portals 1000 NO Doubtful
>>> SCTP 100 NO Conservative value (correct)
>>> Self 100 XXX Correct (doesn't matter anyway)
>>> SM 9000 NO Correct
>>> TCP 100 NO Conservative value (correct)
>>> UDAPL 225 NO Incorrect
>> Now that that patch has been rolled back out, did we come to conclusion here?
>> - OFUD: why do we still even have this?
>> - Portals: does it matter if it gets it wrong? No one will ever multi-rail with it.
>> - TCP: we can add auto-detect code for this (But doesn't have to be right away -- i.e., don't make 1.5.0 wait for it).
>> - UDAPL: I don't think anyone will multi-rail udapl with anything.
>> Was the *real* problem that Brice's OpenFabrics bandwidth was auto-detected incorrectly somehow?
> The first problem came from IB not autodetecting at all by default and
> using 800Mbit/s instead. When forcing autodetect with mca parameters,
> the bandwidth are not perfect but not too bad. When forcing IB manually
> to the right bandwidth value, I can tweak things as needed.
Just to provide some closure on the uDAPL side, we agree with Jeff's
comment that we do not see any demand for multi-rail uDAPL with anything.
But, we will change the uDPAL number to something more reasonable.
Still trying to select an appropriate value.