• Completion. The unavailability or slowness of vol-
unteer resources near the end of the computation can
stretch task completion times.
In the subsections below, we quantify the performance
costs of each of these stages.
4.1 Execution: Cloud Equivalence
We compute the cloud equivalence of a VC system. We
answer the following question: how many nodes in a VC
system are required to provide the same compute power in
FLOPS of a small dedicated EC2 instance? This is similar
to the notion of cluster equivalence in [20]. However, in
that study the equivalence was computed for an enterprise
(versus Internet) desktop grid, and limited to a few hundred
machines.
To compute this cloud equivalence ratio, we used the
statistics for SETI@home presented in [26]. We find that
the average FLOPS of SETI@home is about 514.798 Ter-
aFLOPS. We assume a replication factor of 3 (required
for result verification and time task completion), which is
quite conservative as projects such as World Community
Grid [29] use levels 50% lower. Thus, the effective FLOPS
is about 171.599 TeraFLOPS.
Moreover, there are about 318,380 hosts that were active
in the last 60 days. This means on average, each host con-
tributes 0.539 GigaFLOPS. We ran the Whetstone bench-
mark by means of the BOINC client on an EC2 small in-
stance, and the result was about about 1.528 GigaFLOPS
for the single core allocated on an AMD Opteron Processor
2218 HE. Thus, the cluster equivalence is about 2.83 active
volunteer hosts / 1 dedicated small EC2 instance.
4.2 Platform construction
We compute how long it takes on average for new hosts
to register with a project. We used a trace of registration
time of SETI@home between April 1, 20007 to January 31,
2009. We found the mean rate of registration to be about
351 volunteer hosts per day. We normalize this rate accord-
ing to the cloud equivalence (2.83), giving about 124 cloud
instances per day.
Figure 1 shows how much time it takes before a certain
number of cloud nodes and compute power is reached. For
example, we find that is takes about 7.8 days to achieve a
platform equivalent to 1,000 cloud nodes (1.5 TeraFLOPS),
2.7 months for 10,000 cloud nodes (15.3 TeraFLOPS), and
2.24 years for 100,000 cloud nodes (152.8 TeraFLOPS).
Note this is a best-case scenario as the rates were de-
termined from an extremely popular project, SETI@home.
While we used the mean rate to plot Figure 1, the rate varies
greatly over time. We computed the mean rate per day over
week, month, and quarter intervals. While the mean rate
was roughly the same, the coefficient of variation was as
high as 0.83.
In fact, the rate depends on several factors, such as the
level of publicity for the project. Clearly, the rate of regis-
tration can plateau for some projects. Also, the calculations
did not include the limited lifetimes of some of the nodes.
GAMBAR
4.3 Application Deployment
Assuming a system in steady state, the time to send out
all tasks in a batch can be lengthy as clients use a pull
method for retrieving tasks, and clients only connect to the
server periodically.
Here we summarize the work of Heien et al. [18] where
the authors determined the time to deploy a batch of tasks.
In particular, the authors found that:
L = TQ
P
(1)
L is the time frame during which tasks are distributed, P
is the number of clients, and Q is 1.2 × the number of tasks.
T is the reconnection period, which is a parameter specified
by the project scientist to the client denoting the time that
must expire before it reconnects to the server. By default, in
the BOINC VC system, T is six hours.
Figure 2 shows the time required to assign all tasks in
a batch, assuming a replication factor of 3. We consider
three batch sizes of 100, 1000, and 10000 tasks (and with
replication, a total of 300, 3000, and 30000 tasks). For ex-
ample, deploying a batch with 100, 1000, and 10000 unique
tasks over a platform with 10,000 cloud nodes (or equiva-
lently 28300 volunteer nodes) would take 4.6, 45.8, or 458
minutes, respectively.
