August 2012 - Mpich2-core - mailman3.cels.anl.gov

more mpich2 trac spam (was: "Fwd: [mpich2-maint] #1648: error invalid no_port")
by Dave Goodell 10 Aug '12

10 Aug '12

Systems, We got around 20 spam comments on our trac page overnight, an example of which is forwarded below. It's very tedious and a big waste of time to go in and delete each of these comments. Is there anything that can be done to improve the spam filtering? Note, I have deleted all of the spam comments, so you'll have to look at the mpich2-maint archives (or whatever list is being used for mail distribution) for more details. -Dave Begin forwarded message: > From: "mpich2" <noreply(a)mcs.anl.gov> > Subject: Re: [mpich2-maint] #1648: error invalid no_port > Date: August 9, 2012 9:03:33 PM CDT > To: undisclosed-recipients:; > Reply-To: noreply(a)mcs.anl.gov > > #1648: error invalid no_port > -----------------------------------+---------------------------------------- > Reporter: huki_imoet@… | Type: bug > Status: closed | Priority: major > Milestone: | Component: mpich2 > Resolution: wontfix | Keywords: > -----------------------------------+---------------------------------------- > > Comment(by xiaoliuquan@…): > > Thank you for [http://www.ukchanelbags.co.uk/ chanel bags] another great > article. Where else could anyone get that kind of information in such a > perfect way of writing? > > -- > Ticket URL: <http://trac.mcs.anl.gov/projects/mpich2/ticket/1648#comment:3> > mpich2 <http://www.mcs.anl.gov/research/projects/mpich2> > MPICH2 is a high-performance and widely portable implementation of MPI

1 0

ppcmem validation tool
by Dave Goodell 09 Aug '12

09 Aug '12

An article about a cool tool for validating memory barriers and atomic instructions on weakly ordered PPC and ARM systems: https://lwn.net/Articles/470681/ There's even an interactive online version of the tool you can play with if you like. It would be an interesting student project to apply this tool to the Nemesis lock-free queue algorithms and see if any problems pop out or if memory barriers could be removed. -Dave

1 0

SOCK Tests
by Jim Dinan 09 Aug '12

09 Aug '12

Hi All, FYI, rma/{win_shared,win_shared_noncontig} tests are expected to fail with SOCK, since these functions are now implemented only for Nemesis. ~Jim.

1 0

Fwd: Regarding some more advanced aspects of MPI
by Darius Buntinas 07 Aug '12

07 Aug '12

Another satisfied customer! -d Begin forwarded message: > From: <jgrime(a)uchicago.edu> > Subject: Re: Regarding some more advanced aspects of MPI > Date: July 27, 2012 3:34:37 PM CDT > To: "Darius Buntinas" <buntinas(a)mcs.anl.gov> > > Hi Darius, > > Thanks for the response! > >> I'm not sure how OpenMPI works ... > > I came to this conclusion a couple of days ago; after massive frustration in trying to get OpenMPI to recognise me registering error handlers, and not totally dying when I deliberately killed a process, I finally discovered that this behaviour is by design; OpenMPI simply cannot handle one or more processes dying! As such, it's useless to me. > > I did, however, install MPICH2 and it works like a dream! > > I now have a fault tolerant backend broadcast system, which automatically detects failed nodes and informs the rest of the simulation. Some nice side effects of how I've implemented this are: > > 1. If any node fails, all the other nodes are automatically made aware of this in the background. The specific manner in which I implement the "broadcast" messages also uncovers automatically any other nodes which have died without anyone otherwise noticing. Therefore, *any* use of the backend communications channel will automatically reveal to all nodes exactly which other nodes have crashed. I think this will be very useful to me in future! > > 2. All the backend communications should be very scalable, as the broadcasts are split into smaller "block communications", which are sent to the first node in the specified range. This node retransmits the message to the other nodes in that block range. The block messages themselves are subject to re-splitting, down to some specified minimum block size - at which point they are sent directly using point-to-point communications (the actual messages are very small, so can fit into MPI's "eager" send packets). Hopefully, this should scale very well as we're using what amounts to a tree structure to send in parallel. Speaking of which ... > > 3. The parallel broadcast is itself fault tolerant; there's no single point of failure, and any node can die at any time without stopping the background messages getting to every node. As we define ranges over which the block messages operate, we can easily iterate through the block members from the first member, and pass the message onto the next one which is capable of handling it. The broadcast "tree" for these collective communications is dynamic and fault tolerant, in that sense. > >> -disable-auto-cleanup > > That's exactly what I use! :) > > Kudos to you guys for MPICH2 - it's very impressive, and I have now been able to implement pretty much exactly what I needed without having to use multicasts over IPv4/6, ibverbs or whatever I feared I may have to use. With it being plain old MPI v2, I should be able to deploy systems using this approach to the Blue Gene machines, clusters with Gemini interconnects etc using just the provided software on the clusters themselves, while also taking automatic advantage of the tuned MPI libraries for each. > > I'm really happy with how it's turned out, and the fact that I managed to do so in "pure" MPI. It was a fun technical exercise over a few days! > > Cheers, > > J.

5 5

Fwd: Robert D. Russell Talk "Ongoing work with RDMA at IOL" 8/7th at 2:00 pm
by Rajeev Thakur 06 Aug '12

06 Aug '12

fyi Begin forwarded message: > From: Lynn Valentini <valentin(a)mcs.anl.gov> > Date: August 6, 2012 10:46:00 AM CDT > To: seminars(a)mcs.anl.gov > Subject: Reminder: Robert D. Russell Talk "Ongoing work with RDMA at IOL" 8/7th at 2:00 pm > > ARGONNE NATIONAL LABORATORY > MATHEMATICS AND COMPUTER SCIENCE DIVISION > COMPUTATION INSTITUTE > SEMINAR > > Date: Tuesday, August 7th > Time: 2:00 - 3:00 PM > Location: Argonne National Laboratory, Building 240, Room 4301 > Host: Raj Kettimuthu > > Speaker Robert D. Russell > InterOperability Laboratory > University of New Hampshire > Durham, NH > > > Title: Ongoing work with RDMA at IOL > > > Abstract: > Low latency, high bandwidth interconnects are an important component > of High Performance Computing (HPC) systems, and Remote Direct Memory > Access (RDMA) has become the most popular commercially-available > technology for realizing these interconnects. There are currently > three RDMA families -- InfiniBand, iWARP, and RoCE. As of June, 2012, > 209 (41.8%) of the top 500 Super Computer systems used InfiniBand as > their interconnect. Recently interest in RDMA has grown outside the > HPC community, into financial and commercial data centers, and into > general bulk-data movement applications such as GridFTP. > > This talk describes some of our current work applying RDMA in two > areas: data movement over distance, based on some experiments with > RoCE on the Advanced Networking Initiative (ANI) 100G Testbed; and > development of EXtended Sockets (EXS) as a high-level API for > convenient, efficient access to RDMA in domains where existing APIs, > such as MPI, are not necessarily appropriate. > > Bio: > Bob Russell is an Associate Professor in the Computer Science Department and the InterOperability Laboratory at the University of New Hampshire. > He has a B.A. in Mathematics and Physics from Yale, and a Ph.D. in Computer Science from Stanford. He worked for a number of years at SLAC and CERN, > and has taught at the Ecole Normale Superieure de Lyon, France, and the Technische University Hamburg-Harburg, Germany. He teaches courses in > computer networking, operating systems, and storage systems, and is currently one of the instructors in the OpenFabrics Alliance "Programming > with OpenFabrics Software" Training Course. Since joining the InterOperability Laboratory he has worked on iSCSI and RDMA technologies

1 0

Datatype performance FYI
by William Gropp 02 Aug '12

02 Aug '12

This is just a heads up - inspired by a paper that Torsten will present at EuroMPI, I created some new datatype performance tests (in Torsten's paper, Open MPI does much better than MPICH2). These are drawn from applications and are cases that users expect to perform well. I've also identified some of the reasons: 1) contiguous blocks aren't merged into the parent datatype (nestvec) 2) struct always flattens types, even when this is not appropriate (nestvec2) 3) block index has high overhead for small (e.g., one word) blocks. (indexperf) These should really be compiled with optimization (not currently done, so you'll need to change the Makefile in perf by hand), where 10x performance problems become apparent. In general, the data loop code, except for the simple vector case, has high overhead and is likely to be slow for small blocks, which are common in applications. The data loop concept permits optimizations for this case (see the vector case), but it looks like those were never done. I have a partial fix for the first case, and its pretty easy to turn on or off the struct flattening. Harder is to flatten structs when it makes sense. Fixing #3 requires doing the same sort of code that was used for vectors; that should also be applied to indexed types. Even better is to generate good code based on the platform; I have a student working on that. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

3 9

ERRTEST_NULL Out comm/win/etc parameters
by Jim Dinan 01 Aug '12

01 Aug '12

Hi All, I noticed that there are many MPI_ functions where we don't NULL-check out-parameters. Right now, if you pass NULL as the new handle pointer to a communicator or window creation routine, MPICH will seg fault (example attached). Is this an oversight? More specifically, should I not add: MPIR_ERRTEST_ARGNULL(win) to the window creation routines? ~Jim.

2 2