There are three necessary conditions for prefetching to be useful. First, there must be spare capacity in the whole ``data pipe'' that extends from server's disk to client's cache. This pipe consists of the client's network I/O interface, the network, the server's CPU, and the server's disk and network I/O paths. Second, there must be system resources on the client side for the prefetcher's use. Of special importance are CPU cycles. The prefetcher cannot fulfill its duty if it doesn't acquire CPU cycles promptly, even though the amount of CPU time needed is low. Third, the workload must allow some interval between file accesses so that the prefetched I/O can be started and completed ahead of the demand.
Prefetching proves feasible on both wired and wireless network connections. Although our experiment results suggest that the speedups for these two situations are comparable, the speedup may be even better appreciated by the client at the end of a wireless link. With the slower link, a job lasts longer and more real time can be saved via prefetching. As the ratio of CPU speed to network speed increases, prefetching should provide more benefit. However, there is some subtlety with our implementation scheme. When the ratio is lowered to a certain point, we will no longer be able to depend on the NFS readahead function to bring in subsequent file blocks quickly enough. This difficulty can be tackled by a simple generalization of our initial approach. The prefetcher can always prefetch the first N file blocks (N growing with the CPU/network ratio) and the NFS readahead code can be modified to read the next N-th file block, instead of the immediately next block. Currently, N is simply set to 1.