Some of what you are seeing is the natural result of context switching....some thoughts regarding the results:

1. You didn't bind your procs to cores when running with #procs < #cores, so you're performance in those scenarios will also be less than max. 

2. Once the number of procs exceeds the number of cores, you guarantee a lot of context switching, so performance will definitely take a hit.

3. Sometime in the not-too-distant-future, OMPI will (hopefully) become hyperthread aware. For now, we don't see them as separate processing units. So as far as OMPI is concerned, you only have 512 computing units to work with, not 1024.

Bottom line is that you are running oversubscribed, so OMPI turns down your performance so that the machine doesn't hemorrhage as it context switches.


On Oct 4, 2010, at 11:06 AM, Doug Reeder wrote:

In my experience hyperthreading can't really deliver two cores worth of processing simultaneously for processes expecting sole use of a core. Since you really have 512 cores I'm not surprised that you see a performance hit when requesting > 512 compute units. We should really get input from a hyperthreading expert, preferably form intel.

Doug Reeder
On Oct 4, 2010, at 9:53 AM, Storm Zhang wrote:

We have 64 compute nodes which are dual qual-core and hyperthreaded CPUs. So we have 1024 compute units shown in the ROCKS 5.3 system. I'm trying to scatter an array from the master node to the compute nodes using mpiCC and mpirun using C++. 

Here is my test:

The array size is 18KB * Number of compute nodes and is scattered to the compute nodes 5000 times repeatly. 

The average running time(seconds):

100 nodes: 170,
400 nodes: 690,
500 nodes: 855,
600 nodes: 2550,
700 nodes: 2720,
800 nodes: 2900,

There is a big jump of running time from 500 nodes to 600 nodes. Don't know what's the problem. 
Tried both in OMPI 1.3.2 and OMPI 1.4.2. Running time is a little faster for all the tests in 1.4.2 but the jump still exists. 
Tried using either Bcast function or simply Send/Recv which give very close results. 
Tried both in running it directly or using SGE and got the same results.

The code and ompi_info are attached to this email. The direct running command is :
/opt/openmpi/bin/mpirun --mca btl_tcp_if_include eth0 --machinefile ../machines -np 600 scatttest

The ifconfig of head node for eth0 is:
eth0      Link encap:Ethernet  HWaddr 00:26:B9:56:8B:44  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::226:b9ff:fe56:8b44/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1096060373 errors:0 dropped:2512622 overruns:0 frame:0
          TX packets:513387679 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:832328807459 (775.1 GiB)  TX bytes:250824621959 (233.5 GiB)
          Interrupt:106 Memory:d6000000-d6012800 

A typical ifconfig of a compute node is:
eth0      Link encap:Ethernet  HWaddr 00:21:9B:9A:15:AC  
          inet addr:192.168.1.253  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::221:9bff:fe9a:15ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:362716422 errors:0 dropped:0 overruns:0 frame:0
          TX packets:349967746 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:139699954685 (130.1 GiB)  TX bytes:338207741480 (314.9 GiB)
          Interrupt:82 Memory:d6000000-d6012800 


Does anyone help me out of this? It bothers me a lot.

Thank you very much.

Linbao
<scatttest.cpp><ompi_info>_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users