# Stroll: A Universal Filesystem-Based Interface for Seamless Task Deployment in Grid Computing

Abdulrahman Azab, Hein Meling

► To cite this version:

Abdulrahman Azab, Hein Meling. Stroll: A Universal Filesystem-Based Interface for Seamless Task Deployment in Grid Computing. 12th International Conference on Distributed Applications and Interoperable Systems (DAIS), Jun 2012, Stockholm, Sweden. pp.162-176, 10.1007/978-3-642-30823-9_14. hal-01527637

HAL Id: hal-01527637

https://inria.hal.science/hal-01527637

Submitted on 24 May 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Stroll: a Universal Filesystem-based Interface for Seamless Task Deployment in Grid Computing

Abdulrahman Azab Hein Meling

Dept. of Electrical Engineering and Computer Science
University of Stavanger, Norway

## Abstract

Developing applications for solving compute intensive problems is not trivial. Despite availability of a range of Grid computing platforms, domain specialists and scientists only rarely take advantage of these computing facilities. One reason for this is the complexity of Grid computing, and the need to learn a new programming environment to interact with the Grid. Typically, only a few programming languages are supported, and often scientists use special-purpose languages that are not supported by most Grid platforms. Moreover, users cannot easily deploy their compute tasks to multiple Grid platforms without rewriting their program to use different task submission interfaces.

In this paper we present STROLL, a universal filesystem-based interface for seamless task submission to one or more Grid facilities. Users interact with the Grid through simple read and write filesystem commands. STROLL allows all categories of users to submit and manage compute tasks both manually, and from within their programs, which may be written in any language. STROLL has been implemented on Windows and Linux, and we demonstrate that we can submit the same compute tasks to both Condor and Unicore clusters. Our evaluation shows the overhead of STROLL to negligible. Comparing the code complexity of a STROLL compute task with command-line clients and Grid APIs show that STROLL can eliminated up to 95% of the complexity.

## 1 Introduction

Large-scale distributed computation for scientific applications is on a path to become mainstream, enabling researchers to perform computations that were impossible only a decade ago. Grid computing is an enabling technology in this space, allowing scientists to leverage underutilized compute resources scattered around on the Internet. A recent study [1] shows that typical Windows classroom computers has an average CPU idleness of 97.9%. Moreover, a large number of volunteers contribute compute resources for a wide range of large-scale computing applications [2, 3]. To support scientists in gaining access to this vast collective of compute resources, Grid computing frameworks take the role of coordination and providing an access interface for submitting compute tasks.

However despite its many benefits, the adoption of Grid computing in different scientific communities are perhaps not at the level one might expect or hope. The primary reason for this is complexity [4]. Managing and using a Grid computing framework is a challenging undertaking, and thus limits adoption
to expert programmers capable of, and willing to learn how to program APIs specific to different Grid frameworks. This model is not very approachable for non-computer scientists, such as chemists, biologists, and many others, whom may use domain-specific tools and programming languages. Therefore, a major challenge faced by Grid computing vendors is to provide a *ubiquitous and easy to use interface for accessing the Grid*, enabling domain-specialist programmers to easily develop and deploy Grid computing applications.

The goal of a Grid access interface is to *hide as much complexity as possible, while retaining the necessary flexibility to implement efficient compute tasks*. State-of-the-art Grid computing access typically fall into two categories: (i) manual submission, and (ii) API-based submission. Manual submission includes web-based interfaces and command line tools that enable users to submit tasks for one-shot execution. This approach is not suitable for task deployment from within scientific applications, e.g. repeating a computation in a loop, and analyzing results in-between. The current solution to this need, is to provide a web-service, or some client-side API that can support repeated task submissions. However, a major drawback with this approach is lack of interoperability between different Grid platforms. Even if there were interoperability, most scientific programming languages lack of support for web services and client-side Grid APIs. Moreover, the goal in this paper is to make a variety Grid platforms accessible from any programming language, and to support manual submission by a simple file copy.

This paper presents STROLL, a universal interface for seamless deployment of compute tasks to a variety of Grid platforms. STROLL is based on the ubiquitous filesystem interface, and allows task submission, monitoring, and administration through simple `read()` and `write()` filesystem functions or commands. The interface is implemented as a user space *virtual filesystem (VFS)*, enabling access to it from any application or programming language that can interact with a filesystem. Hence, the approach lends itself well to providing Grid access to domain-specialists whom, although not computer scientists, are expected to have general familiarity with common filesystem operations.

STROLL is implemented on Windows and Linux. The Linux version use the FUSE [5] library, while the Windows version use the Callback File System [6]. In the current implementation, we provide access to two Grid frameworks: Concor [7] and Unicore [8]. A major innovation of STROLL is that it enables users to execute compute tasks on several Grid frameworks, from the programming language of their choice, or by manual submission by means of a simple file copy.

To evaluate the simplicity of using STROLL, we analyzed the program complexity of the task submission procedures of three different Grid tasks written in three different programming languages. We compare the program complexity metrics of STROLL with native Grid submission techniques, using McCabe [9], Halstead [10] and structural software complexity metrics [11], and find that STROLL can reduce code complexity by as much as 95%. We evaluated the performance overhead of running Grid tasks through STROLL versus native Grid access, and find the overhead to be negligible.
## 2 Background and Related Work

Plan 9 [12] was the first operating system to introduce a filesystem-based pattern or style for accessing arbitrary IO systems, e.g. general filesystems, network interfaces, and processes. Similar ideas are provided through the FUSE framework [5], which is used in Unix-like operating systems. FUSE is an integral part of the Linux kernel and is easily installed on OS X systems. On Windows, FUSE-like functionality can be provided by the Callback File System [6].

FUSE consists of: (i) a kernel-space driver that receives control from the kernel for all filesystem commands executed on the virtual path, and (ii) an API through which a user-space program can respond to filesystem commands and take the proper actions. FUSE allows user-space applications to build their own filesystem interface to programmatically control and manipulate the execution of filesystem commands performed on some virtual path.

Attempts at simplifying the interaction with Grid computing systems have been addressed in previous works. The interaction we refer to, takes place at the *interface* between users and the Grid itself. In this work, we do not concern ourselves with the interactions that take place within the Grid infrastructure; instead we leverage existing Grid frameworks and provide an interface for users to operate on multiple Grid frameworks. Most previous efforts to provide Grid access interfaces can be classified into the following categories: (i) Grid portals, (ii) Library-based Grid APIs, and (iii) Web-service interfaces.

Grid portals [13] are web interfaces through which users can upload and submit compute tasks, and eventually download the results. It is designed for manual submission. In many compute-intensive applications, iterative computations that depend on the outcome of previous iterations is necessary, e.g. in stochastic modeling and machine learning [14]. A familiar example is Monte Carlo simulations [15]. For such applications, Grid portals are not suitable.

Library-based Grid APIs provide an interface for programmatic Grid access. These APIs support a range of language bindings, yet they cannot support an arbitrary set of languages. These APIs come in two forms: (1) APIs designed for interoperability, e.g. SAGA [16] and DRMAA [17], and (2) APIs specific to a particular Grid framework [18–21].

Such Grid APIs limits the language choice of the user. As an example, consider an R user that wants to take advantage of a Unicore cluster for solving compute-intensive statistical problems. HiLA [18], which is the main Grid API for Unicore, is based on Java. The R language [22] has no interaction interface for Java. Thus to accomplish this, a user would have to install an R package called rJava [23], and then access the HiLA API through rJava in order to submit compute tasks to Unicore, all of which becomes a tedious and complicated process. There are independent parallel scripting languages, e.g. Swift [24] and Skywriting [25], which to some extent achieves platform independence, but not programming language independence.

To our knowledge, no existing Grid framework provides a pure filesystem interface for interacting with the scheduler and to collect results. While Genesis II [26] does provide filesystem-based access to remote files in data Grids, and
can submit compute tasks, the user still has to manually prepare a JSDL [27] submission script for the compute tasks. Having to prepare a JSDL script retains the complexity sought eliminated by the filesystem interface approach. UEM [28] is a unified execution model for cloud and cluster computing which provides a filesystem interface for execution, monitoring, and control of remote processes. Each process on each node in the system can be shown as a virtual directory. This approach require the user to specify at which node a process should be al-located, making it unsuitable for Grid systems with explicit support for resource management. Parrot [29] is an interposition agent enabling integration between standard UNIX applications and remote storage systems. To use Parrot, users must specify the remote machine's location, and construct special Parrot com-mands which reduces transparency to the user.

STROLL is a VFS based front-end for Grid frameworks through which com-
pute tasks and data files can be submitted to the Grid through filesystem read()
and write() commands. STROLL is novel in that it can support both manual and
programmatic task submission, and is accessible to any programming language
with basic filesystem support. Given its programming language neutrality, there
is no need for new language bindings or extensions. An early version of STROLL
was presented in [30]; this paper is a significant extension. The main additions
in the new version are: support for non-Windows OS and multi-Grid platforms
through drivers, brokering strategy support, and enhanced submission scripting.

3 Task Structure

A Grid task is typically composed of: an executable, input files, and a configura-
tion file, or submission script [31]. In STROLL, a task is represented as a uniquely
named directory containing the appropriate executable, input and output files,
and configuration files. This section describes the task structure used by STROLL.

In STROLL, a regular task contains one executable and a single configuration.
A task can be executed as: (i) *One-shot*, or in (ii) *Batch* [32]. A one-shot task
corresponds to a single submission and needs one CPU to run, while a batch task
consist of multiple parallel submissions with the same executable, but different
input files, and needs multiple CPUs to run. An example task structure of an
R based [22] batch task is shown in Fig. 1. In this directory structure, we separate
between *task files* and *configuration files*. Configuration files are virtual files that
can be queried or updated through *read()* and *write()* calls.

To create a new task, one simply create a new directory under the Grid
filesystem mount point, e.g. `mkdir /stroll/PSM`. This operation automatically
creates task directory structure with virtual files containing default values.

Task files include the executable and input files supplied by user, log files and
output files are created by the Grid framework during execution. The executable
can be: binary, intermediate (e.g. Java or .Net assembly), or a script (e.g. R, Perl,
Python). The runtime required to execute the task has to be configured before
task submission. For batch processing, identically named input files must be
distinguished with a unique index associated with each subtask in the batch.

Configuration files and directories are dynamically created by STROLL, al-
lowing the user to configure, monitor, and control task execution by accessing
<figure><img src="image_2.png" /><figcaption>Fig. 1: Example task structure</figcaption></figure>

the filesystem. The `config` virtual directory contains configuration parameters, each represented by a virtual file naming the parameter and containing the parameter's value. Listing 1.1 shows the simplicity of task submission through a shell script corresponding to the example in Fig. 1.

Table 1 shows the main task configuration parameters/files supported by STROLL. The `status` file can be read by a user to obtain status information about the currently executing task, e.g. `cat status`. The `control` file is used to execute control commands, e.g. submission and forced termination. This can be done by executing a `write()` call on the `control` file, specifying the command as shown in Line 13 of Listing 1.1. The currently supported control commands are:

- `submit`: Submits the task for execution.

- `terminate`: Forces task termination.

- `restart`: Terminate the task and resubmit it.

<table><caption>Table 1: Task parameters (files in the `config` directory)</caption><thead><tr><td>CONFIG</td><td>DESCRIPTION</td></tr></thead><tbody><tr><td>exec</td><td>Executable file name.</td></tr><tr><td>rt</td><td>Runtime environment needed to run the executable, e.g. JVM, R, or CLR.</td></tr><tr><td>wait</td><td>Value true causes the submit command to hold until task termination.</td></tr><tr><td>subtasks</td><td>Number of parallel subtasks to be executed for batch tasks.</td></tr><tr><td>in</td><td>Comma separated list of input files. For batch tasks, the input file names should include a zero based index, e.g. in1,in2,...,in20 for 20 subtasks.</td></tr><tr><td>out</td><td>Comma separated list of output files.</td></tr><tr><td>args</td><td>Comma separated list of task arguments.</td></tr><tr><td>req</td><td>Resource requirements, e.g. memory and load average. The format is a similar to Condor's ClassAd [31], only more compact: LA0.1 && M512 corresponds to LoadAvg&lt;=0.1 && Memory&gt;=512.</td></tr></tbody></table>

Configuration parameters can be set or updated *individually* or *collectively*. Setting parameter values individually is shown in Lines 10-16 of Listing 1.1; e.g. Line 10 names the executable, `parallelPSM.R`, as the value of the `exec` parameter. An alternative is to set parameters collectively by issuing a single `write()` call to the `control` file as shown in Listing 1.2.

STROLL supports both *synchronous* and *asynchronous* submission. Synchronous submission causes the `submit` command to wait until the task has completed and returned results in the output files. Asynchronous submission returns control to
<caption>Listing 1.1: Example task submission from Unix shell</caption>

1 #!/bin/sh
2 # Example with the parallelPSM.R and 20 subtasks
3 cd /stroll
4 # Create PSM task directory inside the virtual path: /stroll
5 mkdir PSM
6 # Copy task files into the task directory
7 cp ~/.parallelPSM.R PSM
8 cp ~/.inp* PSM
9 # Set the configuration parameters:
10 echo 'parallelPSM.R' > config/exec
11 echo 'R' > config/rt
12 echo 'true' > config/wait
13 echo '20' > config/subtasks
14 echo 'inp$(i)' > config/in
15 echo 'out$(i)' > config/out
16 echo 'M128' > config/req
17 # Submit the task
18 echo "submit" > PSM/control
19 # Wait until 'echo' command returns to collect the output
20 cp PSM/out* ~/
21 # Remove the virtual task directory
22 rm -r PSM

<caption>Listing 1.2: Setting parameter collectively</caption>

1 echo "exec=parallelPSM.R;req=M128;rt=R;in=inp$(i);out out$(i),err$(i);wait=true;subtasks=20"
2 > PSM/control

the user immediately, and thus to detect completion, the user must monitor the status file. In STROLL, asynchronous submission is the default; setting the wait option to true in the task configuration (see Table 1) activates synchronous submission (Lines 11 of Listing 1.1). Since the execution models of different Grid systems are not identical, we are currently implementing the shared essential task management functions. Future STROLL versions should include a unified execution model for complex task management functionalities.

## 4 Stroll Architecture

The overall aim of any computational Grid user interface is to provide the ability to submit, monitor, control, and collect the results of compute tasks. STROLL is providing these facilities. Fig. 2a illustrates the architecture of the entire Grid execution model driven by STROLL, and how its various components interact with the targeted Grid frameworks. In the following we describe the various components.

At the top, there is a Grid access front-end, through which a user can manually or programmatically submit compute tasks and collect results by performing read() and write() calls on the filesystem. The execution of these calls is done through a filesystem interface, the fourth layer, which is supported by the operating system. Thus, enabling both access to a local STROLL filesystem, or remotely to a STROLL server. Remote access can be established by having a STROLL server share its virtual access path, and have clients mount it as a network storage. This is a well-known technique and is supported in both Windows and Linux with different protocols, e.g. CIFS, SMB, and NFS. STROLL is placed as the third
layer, and is designed to be accessed either through a local or network filesystem interface. STROLL simply receives Grid access commands, in the form of `read()` and `write()` calls, through the filesystem interface. These are then translated into actual Grid commands according to the target Grid architecture, and submits them to the target Grid client on the second layer. With this design, it is possible to support multiple Grid clients attached to different Grids architectures, e.g. Condor and Unicore. Grid clients can be either command line or API based, and must be granted access to Grid back-ends, the bottom layer.

In case of local filesystem access, users must install both STROLL and clients for each of the targeted Grids on their local machine. This requires that users machines to be granted access to the target Grids. Moreover, in case of network-based filesystem access, only one or a small number of machines needs to have STROLL and Grid clients installed. These machines can act as STROLL servers for other users to gain access to Grid services.

The architecture of STROLL is depicted in Fig. 2b, as the server part of layer 3 in Fig. 2a, which is a shim layer between the filesystem interface and Grid clients. The shim layer is composed of a virtual filesystem driver, a command handler, a broker, and a Grid driver. Next, we describe each of these components.

<figure><img src="image_3.png" /><figcaption>Fig. 2: Architecture</figcaption></figure>

**Virtual filesystem driver:** The VFS driver, CallbackFS or FUSE, is responsible for creating and mounting a virtual storage, and directing the control of all filesystem calls on the virtual storage to the filesystem command handler. The Linux version is based on FUSE and is written in C++, while the Windows version is based on CallbackFS [6] and is written in C# with .Net framework 4.0 [33]. The VFS keeps virtual files for Grid monitoring and control management in the virtual storage, in addition to pointers to the actual task input and output files. The content of the virtual files are stored on disk at a configured location, but could also be kept in memory.

**Filesystem command handler:** This handler is responsible for capturing filesystem commands issued to the STROLL virtual storage(s) and forwarding Grid related commands to the appropriate Grid drivers. On task submission, the handler also contacts the broker for choosing a matching Grid for the task.
**Broker:** The broker is responsible for matching each submitted task with the attached Grids based on the task requirements, e.g. number of nodes and runtime environment. The broker accepts task allocation requests from the command handler, and returns a list of the drivers of the matching Grids. Generally, a Grid is considered to be a match, if it contains enough nodes that satisfy the task requirements, e.g. OS architecture and memory capacity. For deployments with a single Grid platform, the broker is not active. Grid internal brokering is handled by the Grid platform itself.

**Grid driver:** STROLL requires a Grid driver for each Grid architecture that it supports. Currently STROLL can submit tasks to Unicore [8] and Condor [7] Grid frameworks. Each Grid driver is responsible for bridging the STROLL and the Grid architecture. To support multiple Grids of the same architecture, e.g. multiple Condor pools, multiple instances of the associated Grid driver is used. Each Grid driver is connected to a client of the associated Grid, e.g. Condor CLI for Condor and UCC for Unicore. In particular, the Grid driver is responsible for: 1) interpreting Grid commands received from the command handler and to translate them into the associated Grid format, e.g. Condor job ClassAd, 2) submitting the task to the Grid through the Grid client, 3) responding to task monitoring and control commands by gathering the required information and performing the required actions through the Grid client, and finally 4) collecting the task output/error files upon completion and place the files in the task directory in STROLL virtual storage. In the Linux implementation of STROLL, the grid driver is built on the top of SAGA [16], while a simple .Net based driver is built for the Windows implementation.

# 5 Evaluation

In order to evaluate STROLL, we asked ourselves the following two questions: (a) does it actually help the developer, and (b) is the performance overhead acceptable? To address the first question, we decided to compute various code complexity metrics for three different use cases as presented next. The second question is addressed by measuring the performance overhead for the most advanced use case.

## 5.1 Code Complexity Evaluation

We develop three use cases for evaluating the code complexity quantitatively. The first two are embarrassingly parallel and the third is a composite structure which iteratively submits a batch task. The use cases are written in VB.Net, Java, and R. We compare the complexity metrics of our STROLL implementation with current practice using Grid APIs, command-line tools, and in the case of the R language, a language level API called Snow [34] for cluster computing. The following four complexity metrics are used in the comparisons:

1. Lines of Code (LoC).
2. System Complexity (C) [11].

3. McCabe's Cyclomatic Complexity ($\mu$) [9].

4. Halstead's Effort metric (E) [10].

Lines of code is the simplest measure of complexity. System complexity is a high-level design metric which is a collection of two metrics: structural complexity based on the number of fanout modules, and data complexity based on the I/O variables. McCabe's cyclomatic complexity is a measure of testing difficulty based on a control flow representation of the program. Halstead's Effort metric is a measure of program understandability based on the number of operators and the number of operands. For each use case, the metrics are computed only for the part of the program submitting tasks. Thus, let $P$ be the number of procedures involved in the submission for the different alternatives.

**Parallel Matrix Multiplication (VB.Net)** We implement a VB.Net parallel matrix multiplication of two matrices using a simple technique for partitioning the multiplier matrix into a set of sub-matrices. Each sub-matrix is assigned to a subtask for multiplication with the multiplicand matrix.

The code complexity of the task submission part for both synchronous and asynchronous STROLL and two command-line approaches is shown in Table 2. No Grid APIs are included here, since there are no stable .Net APIs for Condor and Unicore. The metrics show that a significant complexity reduction is obtained for STROLL over the other methods, needing only one procedure. For Condor command-line (CLI), two procedures are used for task submission, one in which a job ClassAd [31] is created, and Main. In the Unicore UCC case, the submission is more complex since UCC requires the preparation of a detailed configuration for each subtask. We had to create three procedures: CreateScript for creating the subtask scripts, the Submit procedure, and Main. Note that system complexity and cyclomatic complexity are very large for UCC; normally, $\mu$ should not exceed 10, but due to the complexity of CreateScript, it exceeds this value. Hence, from these results we see that STROLL can reduce the complexity of task submission by more than 90% for the C and $\mu$ parameters compared to UCC. Moreover, STROLL has a 43% and 70% advantage over Condor CLI in the $\mu$ and C parameters, respectively.

**Solving a System of Linear Equations (Java)** Cramer's rule [35] is implemented in Java, and used to solve a system of linear equations represented in matrix multiplication form: $Ax = b$, by calculating matrix determinants. To solve a system of size $n$ using Cramer's rule, determinants have to be computed for $(n+1) \times n$ matrices including the coefficient matrix $A$ and $n$ matrices, one associated with each system variable. The determinants are computed in parallel such that each determinant is computed as a batch task. Since determinant computation is recursive, the parallelism can be branched into $\frac{n!}{2}$ parallel computations with $n-2$ levels. For simplicity we use only one level. Each sub-task of the batch computes a part of the determinant, and $n+1$ batch tasks are necessary to complete the computation.
For this use case, the submission mechanism implements HTC where many
parallel tasks are submitted to the same Grid. The complexity metrics are shown
in Table 2. Task submission is performed through STROLL, Condor API [36],
and Unicore HiLA [18]. As with Condor CLI, two procedures are used also for
Condor API, in which much of the code deals with the matrix partitioning, and
managing multiple submissions. Moreover, the results for HiLA shows that its
complexity is very high, which is due to a very low abstraction level in HiLA.
As for the previous use case, STROLL can significantly reduce complexity: 93%
improvement in cyclomatic complexity and 86% for system complexity compared
to HiLA, and for Condor API, the advantage of STROLL is about 54% for both.

**ECG-CPR Model (R)** In this use case, we take a computationally intensive modeling scenario from our own research group. The project aims to model the relationship between ECG [37] characteristics and CPR [38] quality during cardiac arrest. The model has been developed in R [22] based on the Population Stochastic Modeling (PSM) [39] package. The model estimates population parameters in a mixed effects model based on stochastic differential equations [39], and is computational intensive. It takes about 500 CPU hours, or three weeks of computation for a single run of the model. We profiled the PSM estimation code, and found a function, APL.KF, which is called iteratively to be the most time consuming. To reduce the execution time of the model, we modified APL.KF to submit a batch task. As in the previous use case, task submission is performed through STROLL, Condor API, and Unicore HiLA. In addition, we also compare with an existing HPC cluster tool for R called Snow [34], by implementing another parallel version of APL.KF using the Snow package. In Snow, submission is simply to send the desired procedure along with input parameters to the Snow cluster. Thus, the code complexity is relatively small, as shown in Table 2, yet STROLL is still better in all complexity metrics, except C, where Snow has a 40% advantage over STROLL. In summary, STROLL is still very competitive in terms of overall complexity, even against language level frameworks like Snow.

**5.2 Performance Evaluation**

Next, we evaluate the performance of STROLL in terms of resource consumption and the overhead in task submission.

**Testbed:** Our setup includes two student labs: one with 15 Windows XP machines, each with Intel P4 2.8 GHz dual core CPU and 1 GB memory, and another lab with 20 CentOS Linux machines with identical CPU and memory configuration. The Windows machines were configured as both Condor worker and Unicore target system, and one machine is configured as STROLL server and having both Condor client and UCC installed. The Linux lab is configured as a Condor pool, and each machine has mounted a STROLL directory, through which tasks can be submitted. Submissions are performed through STROLL server to both Windows and Linux machines.

**Resource Consumption:** We evaluate the performance of STROLL in terms of CPU and memory consumption on STROLL server by testing the STROLL
network model through recording CPU and memory usage on STROLL server during the concurrent submission of many tasks from other machines in the LAN. Similar to Unicore service orchestrator [40], STROLL carries out task submission from the server, the case in which the load on the server is directly proportional to the number and size of submissions. We submitted 10 matrix-multiplication batch tasks from the LAN through the shared STROLL network drive.

<table><caption>Table 2: Code complexity for different submission methods. Least complex (best) is shown in bold.</caption><thead><tr><th></th><th>Submission method</th><th>LoC</th><th>P</th><th>C</th><th>μ</th><th>E</th></tr></thead><tbody><tr><td rowspan="4">Parallel Matrix × (VB.Net)</td><td><strong>Stroll-Sync</strong></td><td><strong>28</strong></td><td><strong>1</strong></td><td><strong>100.73</strong></td><td><strong>4</strong></td><td><strong>3.1 × 10<sup>4</sup></strong></td></tr><tr><td>STROLL-ASYNC</td><td>32</td><td>1</td><td>144.69</td><td>5</td><td>3.5 × 10<sup>4</sup></td></tr><tr><td>Condor CLI</td><td>74</td><td>2</td><td>339.66</td><td>7</td><td>6.3 × 10<sup>4</sup></td></tr><tr><td>UCC</td><td>255</td><td>3</td><td>1511.37</td><td>49</td><td>> 10<sup>6</sup></td></tr><tr><td rowspan="4">Cramer's rule (Java)</td><td><strong>Stroll-Sync</strong></td><td><strong>44</strong></td><td><strong>1</strong></td><td><strong>144.77</strong></td><td><strong>4</strong></td><td><strong>7 × 10<sup>4</sup></strong></td></tr><tr><td>STROLL-ASYNC</td><td>46</td><td>1</td><td>169.79</td><td>5</td><td>7.1 × 10<sup>4</sup></td></tr><tr><td>Condor API</td><td>139</td><td>2</td><td>320.2</td><td>9</td><td>10.2 × 10<sup>4</sup></td></tr><tr><td>Unicore HiLA</td><td>1043</td><td>13</td><td>998.5</td><td>56</td><td>> 10<sup>6</sup></td></tr><tr><td rowspan="5">ECG-CPR Model (R)</td><td><strong>Stroll-Sync</strong></td><td><strong>22</strong></td><td><strong>1</strong></td><td><strong>50.37</strong></td><td><strong>3</strong></td><td><strong>8.1 × 10<sup>3</sup></strong></td></tr><tr><td>STROLL-ASYNC</td><td>26</td><td>1</td><td>64.33</td><td>4</td><td>8.8 × 10<sup>3</sup></td></tr><tr><td>Snow</td><td>29</td><td>2</td><td><strong>30.83</strong></td><td>5</td><td>16.3 × 10<sup>3</sup></td></tr><tr><td>Condor API</td><td>47</td><td>2</td><td>209.5</td><td>7</td><td>94.1 × 10<sup>3</sup></td></tr><tr><td>Unicore HiLA</td><td>950</td><td>14</td><td>1179.7</td><td>56</td><td>> 10<sup>6</sup></td></tr></tbody></table>

Fig. 3 presents two snapshots of CPU and Memory consumption by STROLL during the submission and execution of the 10 tasks to Condor and Unicore respectively. Each task included five subtasks, and the total input size of each task equals to 38.5 MB in case of Condor and 46.5 MB in case of Unicore. Fig. 3a and 3b presents the CPU consumption by only STROLL threads as a percentage of CPU time, while memory consumption is computed as the portion of the physical memory, in 10 MBytes, which is consumed by STROLL threads. # submissions is the total number of currently running tasks. The 10 tasks are submitted in a similar sequence to both Condor and Unicore.

In Fig. 3a and 3b, it is clear that STROLL introduces low CPU and memory consumption throughout the concurrent executions. This small overhead is due to the interaction with the Grid clients, condor CLI and UCC, together with the created monitoring threads. It is also noticed that STROLL introduces more CPU consumption in case of submitting to Unicore, which was expected due the many threads usually created by the UCC. It is also noticed that task execution is faster in Condor than in Unicore, which is a pure performance difference between the two frameworks and irrelevant to STROLL.

**Task submission overhead:** To evaluate the time overhead of STROLL, we compared the time consumed in task submission in case of submission through STROLL with that in case of submission through Grid APIs. In case of Grid APIs, Task submission time (TST) is the time taken by the API procedures to construct and submit the task to the Grid using the local privileges. In case of STROLL, TST is the time interval starting from detecting the submission
filesystem command through task construction to task submission through the
Grid client to the local broker.

<figure><img src="image_4.png" /><figcaption>Fig. 3: STROLL resource consumption under concurrent submissions.</figcaption></figure>

TST is more effective for evaluating the time overhead of STROLL other than
the total execution time since task execution is entirely managed by the Grid
broker. Fig. 4 presents the task submission time of five internal batch tasks,
from the ECG-CPR model, with different sizes: 5, 10, 20, 30, and 40. Each task
has been submitted five times using the following configurations: Condor API
(through rJava), HiLA (through rJava), and synchronous STROLL submitting
to Condor and Unicore. The presented values are the median values of the five
runs.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Submission time for batch tasks of different sizes</figcaption></figure>

It is noticed that the submission time increases with the task size, which can be
plained as follows: for a batch task submission, each subtask has to be submitted
individually to the broker queue in addition to creating a separate monitoring
process/object at the client. It can be seen that STROLL-Condor actually sub-
mits faster than Condor API. The reason is that Condor API, being based on
Java, turns out to be slower in task submission than STROLL, which interacts
directly with Condor CLI. In the Unicore experiment, STROLL is slightly faster
than HiLA due to the overhead caused by HiLA for creating a separate object for
each subtask, while STROLL uses UCC for submission. Overall, time consumed
in task submission through STROLL is relatively small compared to that in case
of submission through Grid APIs.

# 6 Conclusion

Given the complexity of Grid computing middleware, providing an easy to use
interface for task submission is a significant challenge. In this paper, we proposed
STROLL, a universal filesystem-based interface for seamless task submission to
one or more Grid computing facilities. STROLL provides drivers for both Condor
and Unicore, enabling non-expert users to submit compute tasks to the Grid
both manually and programmatically. Our evaluation indicate that the overhead
imposed by STROLL over native Grid clients is negligible, nevertheless concurrent
submission of batch tasks through one STROLL server can be resource consuming.
We have also demonstrated that the complexity of the compute task, written
using STROLL can reduced the program complexity significantly.

We are planning to expand the testing scope to include the evaluation of STROLL server delays in case of a considerable number of concurrent submissions using a powerful STROLL server. In addition, we are currently building a composite task model to allow building workflow tasks as directory structures together with the support for inter-task communication. Also to include drivers for other Grid frameworks, e.g. Globus and gLite. And finally, we are planning to build a security model in which Grid user privileges are mapped to filesystem privileges.

# References

1. P. Domingues, P. Marques, and L. Silva, "Resource usage of windows computer laboratories," in *ICPP Workshops*, 2005, pp. 469 – 476.

2. D. P. Anderson, "Public Computing: Reconnecting People to Science," in *Shared Knowledge and the Web*, Madrid, Spain, Nov. 2003.

3. B. McConnell, *Beyond Contact: A Guide to SETI and Communicating with Alien Civilizations*. O'Reilly, 2001.

4. M. Bijsterbosch et al., "DRIVER, Digital Repository Infrastructure Vision for European Research II," Technology Watch Report, Dec. 2008.

5. "Filesystem in userspace – http://fuse.sourceforge.net/."

6. "Callback File System – http://www.eldos.com/cbfs/," 2011.

7. M. Litzkow, M. Livny, and M. Mutka, "Condor - a hunter of idle workstations," in *ICDCS*, June 1988.

8. D. W. Erwin and D. F. Snelling, "Unicore: A grid computing environment," in *ECPP*, 2001, pp. 825–834.

9. T. J. McCabe, "A complexity measure," in *IEEE Trans. Softw. Eng.*, 1976.

10. M. H. Halstead, *Elements of Software Science (Operating and programming systems series)*. NY, USA: Elsevier Science Inc., 1977.

11. D. N. Card and W. W. Agresti, "Measuring software design complexity," *The Journal of Systems And Software*, vol. 3, no. 8, June 1988.

12. R. Pike et al., "The use of name spaces in Plan 9," *SIGOPS Oper. Syst. Rev.*, vol. 27, no. 2, pp. 72–76, 1993.

13. X. D. Wang, X. Yang, and R. Allan, "Top ten questions to design a successful grid portal," in *SKG*, 2006, pp. 18–24.
14. Y. Saad, *Iterative Methods for Sparse Linear Systems*, 2nd ed. Philadelphia, PA, USA: Society for Industrial and Applied Mathematics, 2003.

15. D. Abramson, J. Giddy, and L. Kotler, "High performance parametric modeling with nimrod/g: Killer application for the global grid?" 2000.

16. T. Goodale et al., "Saga: A simple api for grid applications. high-level application programming on the grid," in *Comput. Methods in Science and Tech.*, 2006.

17. J. Herrera, E. Huedo, R. S. Montero, and I. M. Llorente, "Developing grid-aware applications with drmaa on globus-based grids," 2004.

18. B. Hagemeier, R. Menday, B. Schuller, and A. Streit, "A universal api for grids," in *Cracow Grid Workshop*, July 2007.

19. C. Chapman et al., "Condor birdbath: Web service interfaces to condor," in *UK e-Science All Hands Meeting*, Nottingham, UK, 2005.

20. "Grid ASCII Helper Protocol - http://www.cs.wisc.edu/condor/gahp/."

21. D. Wegener et al., "GridR: An R-based tool for scientific data analysis in grid environments," *Future Gener. Comput. Syst.*, vol. 25, pp. 481-488, April 2009.

22. R Development Core Team, *R: A Language and Environment for Statistical Computing*, R Foundation for Statistical Computing, Vienna, Austria, 2011.

23. S. Urbanek, *rJava: Low-Level R to Java Interface*, 2009. [Online]. Available: http://cran.r-project.org/package=rJava

24. M. Wilde et al., "Swift: A language for distributed parallel scripting," *Parallel Computing*, vol. 37, no. 9, pp. 633-652, 2011.

25. D. G. Murray and S. Hand, "Scripting the cloud with skywriting," 2010.

26. M. M. Morgan and A. S. Grimshaw, "Genesis ii - standards based grid computing," in *CCGRID*, 2007, pp. 611-618.

27. A. Anjomshoaa et al., *Job Submission Description Language Specification*, 2005.

28. E. van Hensbergen, N. P. Evans, and P. Stanley-Marbell, "A unified execution model for cloud computing," in *LADIS*, October 2009.

29. D. Thain and M. Livny, "Parrot: Transparent user-level middleware for data-intensive computing," *Scalable Computing: Practice and Experience*, vol. 6, no. 3, pp. 9-18, 2005.

30. A. Azab and H. Meling, "A virtual file system interface for computational grids," in *EUNICE*, 2010, pp. 87-96.

31. "Condor submit description file." [Online]. Available: http://www.cs.wisc.edu/condor/manual/v7.6/condor submit.html

32. "Batch processing - http://www.hpcx.ac.uk/support/documentation/user-guide/hpcxuser/batch processing.html," 6 Retrieved 2011.

33. "Microsoft .Net - http://www.microsoft.com/net/," 2011.

34. L. Tierney, A. J. Rossini, N. Li, and H. Sevcikova, "Snow: Simple Network of Workstations," Nov. 2011.

35. C. B. Boyer, *A History of Mathematics*, 2nd ed. Wiley, 1968, p. 431.

36. "Condor Java API." [Online]. Available: http://staff.aist.go.jp/hidenakada/condor.java api/

37. S. Bowbrick and A. Borg, *ECG complete*. Churchill Livingstone, 2006.

38. S. P. "History of cardiopulmonary-cerebral resuscitation," in *Cardiopulmonary Resuscitation*, New York, 1989, pp. 1-53.

39. S. Klim et al., "Population stochastic modelling (psm)-an r package for mixed-effects models based on stochastic differential equations," *Comput. Methods Prog. Biomed.*, vol. 94, pp. 279-289, June 2009.

40. B. Schuller et al., "Chemomentum - unicore 6 based infrastructure for complex applications in science and technology," in *Euro-Par Workshops*, 2007, pp. 82-93.