Grid-Enabling Applications with JGRIM - Cloud, Grid and High Performance Computing: Emerging Applications - page 53

Figure 5. AET of the k-NN application (left) and the image restoration application (right)

Figure 6. Network traffic of the k-NN application (left) and the image restoration application (right)

we used five pictures of various sizes (0.4 MB,
0.9 MB, 1.5 MB, 1.8 MB and 2.4 MB). We aver-
aged the execution time (AET) and accumulated
the network traffic for 10 executions per test
(deviations were around 5%). Loopback network
traffic was filtered out, as it does not consume
bandwidth and it is negligible compared to LAN
and WAN traffic. To capture network traffic, we
used the tcpdump 2 network monitoring program.
Figures 5 and 6 show the obtained results. As
expected, JGRIM behaved similar to the alterna-
tives. Besides, the use of JGRIM policies (caching
and mobility) greatly improved both performance
and network usage.
When not using the caching policy, the JGRIM
variant of k-NN incurred in a performance over-
head of 10-15% compared to its Satin counterpart.

However, this overhead was associated to perform
service discovery, a key Grid feature that is not
present in Satin and ProActive. Besides, caching
allowed JGRIM to continue using discovery
-which intuitively translates into overhead- and
at the same time to stay very competitive. Fur-
thermore, ProActive k-NN performed poorly.
Roughly, ProActive is strongly oriented towards
simplifying the deployment of Grid applications,
which contributes to make application setup
slower. In principle, these results suggest that
ProActive is not suitable for applications whose
execution time is similar than their setup time.
Moreover, caching significantly reduced network
traffic, which is a consequence of performing less
remote dataset accesses. It is worth noting that
Satin and ProActive k-NN might have benefited