Future Work

This section describes the follow-ups possible after the work described in this paper. Due to time constraints, the following areas were not able to be considered. Only after these problems are addressed, will the goals of this paper be fully realized.

• The Alpha Farm needs to be reserved, and guarantee no other processes are run, while we do timings.

• OSF/1 allows the ability to specify a signal number to signal when a single or group of asynchronous I/O calls are completed. Currently, we must poll, by checking all outstanding aio calls in the queues. This would lend to a tighter server loop body, and possibly more efficient code. The sooner we can find out a read has finished, the sooner we can send the data back to the requesting client. Small speedups in these synchronous parts could contribute to significant overall system speedups.

• Porting of real applications, like the AVHRR earth science applications pathfinder and climate used in a previous client-server study [1]. The small benchmarks studied here were suitable to show promise, but real applications are needed to stress the system in less artificial ways.

• Investigate different scheduling algorithms more tailored to high bandwidth Parallel I/O. Perhaps forcing the server to make several passes through the server loop waiting for work to be performed, before yielding to the client thread. This is one of the advantages to running on a machine that has kernel visible threads, in that more precise control is possible. On the development platform, the IBM SP-2, the threads were not kernel visible, and little more than changing priorities was possible.

• Use all four processors on a node to do useful work. For example, since the programs studied are SPMD style, we could have one server process ``dedicated'' to one CPU by only running four processes total. The other three can be clients. As described in 2.2, Jovian-2 can be configured in several ways. Simple modifications can force a process to be all client, or all server. An interesting extension would be to run more than four processes, as in four client and one server, and see what scheduling control is needed to get acceptable performance.

• The issue of main memory usage has been conveniently ignored. Looking at either a fixed total usage scheme, or an application controlled scheme will be useful. Applications that need to consume so much data, also may have a large memory footprint as well. Allowing Jovian-2 to consume as much memory as possible, can easily cause thrashing. Application ``hints'' to Jovian-2 is probably the most robust way to solve the problem. This needs to be explored further.

• Flow control has also been ignored. It can be shown that over-running the servers can cause a large backlog of messages. As is routing protocols, some sort of flow control, or back-off scheme should be used to avoid a bad problem getting worse.