On Sep 8, 2010, at 5:02 PM, Rolf vandeVaart wrote:
> The way the code is currently written, it does not run the autodetect by
> default. What happens is it takes a look at
> the bandwidth value. If the bandwidth value is 0, it will run the autodetect
> code.
This seems like a no-brainer: we s
On 9/8/2010 10:41 AM, Jeff Squyres wrote:
On Sep 8, 2010, at 2:09 PM, Brice Goglin wrote:
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.
That sho
On Sep 8, 2010, at 2:09 PM, Brice Goglin wrote:
>> 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.
That shouldn't be the case. Was it autode
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 BandwidthAuto-detect Status
Elan200
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 BandwidthAuto-detect Status
>> Elan2000NO
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 BandwidthAuto-detect Status
> Elan2000NO Correct
> GM 250 NO
Le 03/09/2010 17:33, George Bosilca a écrit :
>>> GM 250 NO Doubtful
>>>
This one should be 2000 (assuming nobody runs Myrinet 1280 from the 90s
anymore :))
>>> MX 2000/1 YES (Mbs)Correct (before the patch)
>>> OFUD800
On Fri, Sep 3, 2010 at 3:47 PM, Jeff Squyres wrote:
> It might be worth having even a Linux-specific way to auto-detect, just for
> this use case (which is becoming more common -- 1GB LOM and a 10GB non-iWARP
> NIC).
The file:
/sys/class/net/ethX/speed
should contain the current speed and is
On Sep 3, 2010, at 09:50 , Brice Goglin wrote:
> Le 03/09/2010 15:38, George Bosilca a écrit :
>> Jeff,
>>
>> I think you will have to revert this patch as the btl_bandwidth __IS__
>> supposed to be in Mbs and not MBs. We usually talk about networks in Mbs
>> (there is a pattern in Ethernet 1G
Le 03/09/2010 15:38, George Bosilca a écrit :
> Jeff,
>
> I think you will have to revert this patch as the btl_bandwidth __IS__
> supposed to be in Mbs and not MBs. We usually talk about networks in Mbs
> (there is a pattern in Ethernet 1G/10G, Myricom 10G). In addition the
> original design of
On Sep 3, 2010, at 9:38 AM, George Bosilca wrote:
> I think you will have to revert this patch as the btl_bandwidth __IS__
> supposed to be in Mbs and not MBs. We usually talk about networks in Mbs
> (there is a pattern in Ethernet 1G/10G, Myricom 10G).
This is why I shouldn't commit patches fo
Jeff,
I think you will have to revert this patch as the btl_bandwidth __IS__ supposed
to be in Mbs and not MBs. We usually talk about networks in Mbs (there is a
pattern in Ethernet 1G/10G, Myricom 10G). In addition the original design of
the multi-rail was based on this assumption, and the mul
Thanks; committed in r23712.
Can you file CMRs for 1.4 and 1.5? Thanks.
On Sep 3, 2010, at 3:53 AM, Brice Goglin wrote:
> For some reason, the MX btl sets btl_bandwidth in megabits/s instead of
> megabytes/s. So we get crazy btl_weights in case of heterogeneous
> multirail. And --mca btl_mx_ba
13 matches
Mail list logo
