For the tests, a FORTRAN 90 implementation of CG (conjugate gradient) algorithm was used. The CG method is a simple iterative parallel solver for linear equations and it has the same behavior and communication pattern as DOUG.
4.4.1 Test algorithm
The main part of the algorithm consists of the iterations with varying point to point and collective communication calls. During point to point com-munication every process sends messages (several kilobytes each) to about three other processes. The collective communication sums one floating point value of every process and delivers the result to all processes (MPI Allreduce).
The starting snippet of the CG iteration code was instrumented with !!CPR potentialcheckpoint comment and new set of source files were generated.
The Laplacian matrix with 90000 unknowns was generated for the algo-rithm containing about 450000 non-zero values. Total number of iterations was over 1000 to solve the problem with 10−11 precision.
4.4.2 Test setup
The application was developed on a single machine with gfortran 4.1.2 com-piler and OpenMPI 1.1implementation of MPI. Later, the performance tests were run on a cluster consisting of eight 1000MHz Dual Core AMD Opteron processors. The cluster runs GNU/Linux operating system, has Intel For-tran 9.1 compiler andLAM/MPI 7.1.2implementation of MPI installed. No source changes to the application were needed to run with different com-piler and MPI library. All checkpoints were saved to and restored from the mounted NFS tree.
The CG algorithm was run in six modes 1. original CG (Original)
2. generated CG with only application data checkpointing code, MPI calls were left unchanged (+Data)
3. generated CG with only application data checkpointing code and in-strumented MPI point to point communication calls (MPI Send,MPI Recv, MPI ISend,MPI IRecv,MPI Wait), MPI collective communication calls were left unchanged (+Point to point)
4. generated CG with all functionality but without taking checkpoints (+Collectives)
5. generated CG with all functionality and taking single checkpoint (+Check-point)
6. restoring from the saved checkpoint (Restore).
All modes were run with 1, 4, 9 and 16 processors 5 times and run times of the algorithm were recorded. The highest and lowest times were ignored and mean of 3 other values was taken. The recovery mode does not have timings recorded because they are meaningless —gettime()function call was not instrumented and the resulting run time was generally the time between two executions of the algorithm. All modes worked without errors and gave correct answers.
4.4.3 Test results
Table 4.2 presents mean values of run times given in seconds and ratio coeffi-cients to the original code execution time. The time intervals were measured byMPI Wtimecalls and synchronized withMPI Barriercalls, so they do not include start up time of CG application and MPI environment. The total size of the saved global checkpoint for each case is given in the last row.
The results show that there is no substantial difference until collective communication is wrapped by the the coordination layer. The problem is that it requires additional MPI Allgather call for every collective MPI operation to collect remote epoch numbers. This approach is very inefficient when number of processors gets high.
The overhead from saving the program state is noticeable although not large. Two major factors may affect the result:
• process is stalled when taking local checkpoint (copy-on-write helps with SLC solutions)
mode/processors 1 4 9 16
Original 13.42 5.62 4.01 4.45
1 1 1 1
+Data 13.2 5.33 4.41 4.76
0.98 0.95 1.1 1.07
+Point to point 12.31 5.16 4.51 4.76
0.91 0.92 1.12 1.07
+Collectives 12.26 5.54 4.97 10.25
0.93 0.99 1.24 2.3
+Checkpoint 12.99 5.36 6.55 10.91
0.97 0.95 1.63 2.45
Restore OK OK OK OK
Size 21M 1x12.4M+
3x3.2M
1x10.7M+
8x1.6M
1x10M+
15x1.08M Table 4.2: Performance test results
• simultaneous checkpoint transfers over the network may overload it, so both state capture speed and basic algorithm communications are affected.
Tests with larger input data, more processors and longer run time should clear if the overhead resulting from checkpoint data transfer is noticeable.
Chapter 5
Conclusion and future plans
Using the overview given in the first three chapters of this work we found that automated application-level checkpointing could be the best fault tolerance solution for scientific applications with available source code. As a result we have implemented and tested a proof of concept solution for FORTRAN 90 programs that use MPI.
This chapter summarizes fault tolerance techniques and the effort made toward automated application-level checkpointing. It also presents some ideas of why it is difficult to implement fault tolerance and what can be done to improve the situation.
5.1 Conclusions for AALC effort
Implementing AALC with a layer over MPI is a challenging task which re-quires much effort in designing and tuning the coordination layer and has many hidden obstacles. The performance issues must be taken seriously and possible solutions in the coordination layer must be carefully evaluated.
Nevertheless, the proposed solution may altogether take less effort than SLC. This is because it uses MPI standard and does not require any changes once implemented. With the SLC the situation may be different [24]:
By far the most challenging aspect of implementing BLCR was to keep it working as the Linux kernel continued to evolve.
We have showed that when such solution is implemented, adding
check-pointing functionality to the scientific application becomes easy. The result-ing code is fully portable runnresult-ing on potentially any hardware and software platform that has FORTRAN compiler and MPI implementation.