Grid is a non-dedicated and dynamic computing environment. Consequently, different programs have to compete with each other for the same resources, and resource availability varies over time.That causes the performance of user programs to degrade and to become unpredictable. For resolving this problem, we propose a multi-layer resource reconfiguration framework for grid computing. As named, this framework adopts different resource reconfiguration mechanisms for different workloads of resources. We have implemented this framework on a grid-enabled DSM system called Teamster-G. Our experimental result shows that our proposed framework allows Teamster-G not only to fully utilize abundant CPU cycles but also to minimize resource contention between the jobs of resource consumers and those of resource providers. As a result, the job throughput of Teamster-G is effectively increased.

No abstract

No abstract

Conventional data grid systems require the application to access remote data through explicit APIs, consequently sacrificing user transparency. Thus, some systems enable the application to transparently access remote data by copying the entire file to a user's local storage before executing the application, even when only a tiny file fragment is required. Such an approach consumes unnecessary transmission time and storage space, with the additional problem of maintaining replica synchronization. Traditionally, replica consistency treats shared files as read-only, consequently sacrificing guaranteed replica consistency. This paper presents a DSM-based fragment-level file sharing framework called "Spigot". Spigot allows the users to design their applications with the POSIX I/O interface. Moreover, Spigot transfers only the necessary file fragments on user demand, thereby reducing transmission time, wasted network bandwidth and required storage space. Data waiting time is further reduced by overlapping data transmission and data analysis. The DSM concept maintains replica synchronization. Real experiments show reduced turnaround times in data-intensive applications.

No abstract