I would say threading overhead as might be seen by an application. The testsin www.mcs.anl.gov/~thakur/thread-tests also try to measure that. I willpoint Sameer at those.Rajeev-----Original Message-----[mailto:owner-mpich2-core@mcs.anl.gov] On Behalf Of Pavan BalajiSent: Wednesday, January 30, 2008 2:57 PMSubject: Re: [mpich2-core] MPICH2 Threading OverheadYeah, I misunderstood the code. Darius pointed it out too.However, itagain comes back to what exactly we want to measure -- threadingoverhead in MPICH2 or threading overhead in the overall communicationand networking stack?-- PavanOn 01/30/2008 01:57 PM, Rajeev Thakur wrote:Well the original code IBM sent does not have this 1process limitation. Seeattached. The threads of a process communicate with thethreads of anotherprocess. I think that is a better test. Why did we change it?Rajeev-----Original Message-----[mailto:owner-mpich2-core@mcs.anl.gov] On Behalf Of Darius BuntinasSent: Wednesday, January 30, 2008 1:07 PMSubject: Re: [mpich2-core] MPICH2 Threading OverheadI just want to check what the benchmark should do.My understanding from the conference calls and Sameer'sslides is thatthey're interested in the case where multiple threads of aprocess aresending/receiving to/from different processes. This allowsthe processto use multiple DMAs concurrently.Right now, we've been testing the case where one process issending/receiving with itself. So moving the locks around VCs maydecrease the size of the CS, but will still serialize.So what's the test we want to run?I imagine something like P processes each with P-1 threadswhere eachthread is communicating with a different process. Butthen we need amachine with P(P-1) cores.On the 8-core nodes we have, we can run 3 processeswith 2 threadseach. But I think we need more threads to really stress things.It seems that what we can see from the one or two processesis the justthe effect of the size of the CS.Comments?-d--Pavan Balaji