MSRPC-FM will be an implementation of Microsoft's adaptation of DCE RPC that uses Illinois Fast Messages as a communications mechanism. This will allow MSRPC and DCOM to be tested using Myrinet, a high-performance network.
We have laid out the expected progress for each remaining week in the semester. We will start with benchmark implementation and study of the existing system, followed by source code discovery. We will proceed to modification of MSRPC to use FM, and finish with benchmarking and analysis of the changes in higher-level performance.
At the end of the semester, we expect to have a working MSRPC interface that uses FM and microbenchmark suites for MSRPC and DCOM. If time permits, we will analyze the benchmark results for publication. The MSRPC-FM product will not be release-stable at the end of the semester.
We are going to develop a performance suite for DCOM which consists of a series of tests which are specifically designed to determine measurements such as latency, throughput and bandwidth. These tests will be applied to three cases. The first case is the measurement of DCOM as it is distributed on top of Win RPC. We will include tests using local machine calls as well so that COM's performance locally can be used as a control indicating ideal interface method calling behavior. Then we will apply the same battery of tests to DCOM on top of a modified RPC. This RPC will be adapted to run on top of FM. This will indicate whether or not any of the layers lower than DCOM , if modified, can provide any gains in performance. Concurrently with the second case, we should be able to determine the tests' performance under DCOM by measuring the appropriate intervals marked by entering and leaving the RPC level.
We have set one or more milestones for the end of each week. These milestones are assigned to weeks based on task dependencies (outlined in the dependency chart appended to this document) and expected time for completion. Due to the ambitious nature of this project, no slip time has been planned. Should schedules slip, some portion of the project will have to be dropped.
During the first week, a Win32 application will be developed which will execute what is necessary for the testing configurations. Basically, the application will consist of two objects hosted by individual servers. One object will be used to drive the tests, while the other will be instantiated remotely and will either be a target for remote method calls or will act as a source firing method calls upon the first object for the throughput tests. It is necessary for us to determine the exact mechanisms for testing that we will use. An initial approach will be enough to begin, but refinements will undoubtably occur as our experience progresses. Also, during this first week, we will need to determine which timing mechanisms will be used by the application.
The first milestone will be the completion of a set of microbenchmarks which will test the latency and throughput of an implementation of DCOM. This will likely have a command-line interface and log information to a database file.
Week two will be our first analysis of the Win RPC source code. We will determine how the RPC can be modified so that it can be implemented on top of FM. Through this period of discovery, we will almost certainly modify our testing approaches so that we can minimize any unnecessary overhead. At the end of the week, our milestone will be a road map through the DCOM source that can be used to identify targets for replacement with FM calls.
Using the microbenchmarks developed in week one and refined in week two, we will test the current implementation of DCOM over standard MSRPC. We would also like to test the performance of COM (to provide an ideal target for ORPC performance).
Using the roadmap developed in week two, we will replace the portions of MSRPC that use the network with equivalent Fast Messages calls. The exact extent of this portion of the project will be determined by our code discovery work on the second week.
Again using our DCOM microbenchmarks, we will test the performance gained by using MSRPC-FM instead of the current implementation of MSRPC.
To understand the limitations of the underlying RPC layer, and the overhead introduced by DCOM itself, we would like to run similar microbenchmarks on top of the basic FM-based RPC layer. Performance from test II would then be represented as a fraction of optimal performance. (This depends on how easy it is to extract the MSRPC interface from DCOM.)
The final step in the project will be the analysis and presentation of data collected. Currently we plan to measure latency as a function of buffer size for remote invocations, and throughput, or calls serviced, as a function of buffer size and number of call requests made per second. Bandwidth can be derived from throughput and buffer size.