There is some overhead involved when activating the current C/R functionality in Open MPI due to the wrapping of the internal point-to-point stack. The wrapper (CRCP framework) tracks the signature of each message (not the buffer, so constant time for any size MPI message) so that when we need to quiesce the network we know of all the outstanding messages that need to be drained.
So there is an overhead, but it should not be as significant as you have mentioned. I looked at some of the performance aspects in the paper at the link below: http://www.open-mpi.org/papers/hpdc-2009/ Though I did not look at HPL explicitly in this paper (just NPB, GROMACS, and NetPipe), I have in testing and the time difference was definitely not 2x (cannot recall the exact differences at the moment). Can you tell me a bit about your setup: - What version of Open MPI are you using? - What configure options are you using? - What MCA parameters are you using? - Are you building from a release tarball or a SVN checkout? -- Josh On Mar 3, 2010, at 10:07 PM, 马少杰 wrote: > > > 2010-03-04 > 马少杰 > Dear Sir: > I want to use blcr and openmpi to checkpoint, now I can save check > point and restart my work successfully. How erver I find the option "--am > ft-enable-cr" will case large cost . For example , when I run my HPL job > without and with the option "--am ft-enable-cr" on 4 hosts (32 process, IB > network) respectively , the time costed are 8m21.180s and 16m37.732s > respctively. it is should be noted that I did not save the checkpoint when I > run the job, the additional cost is caused by "--am ft-enable-cr" > independently. Why can the optin "--am ft-enable-cr" case so much system > cost? Is it normal? How can I solve the problem. > I also test other mpi applications, the problem still exists. > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
