TOWARDS A PERFORMANCE MODEL
FOR RESOURCE ALLOCATION IN TYCOON
Fernando Rodríguez, Felix Freitag, Leandro Navarro
Department of Computer Architecture
Technical University of Catalonia, Jordi Girona 1-3,
08034 Barcelona, Spain
Email: {frodrigu, felix, leandro}@ac.upc.edu
ABSTRACT
Economic resource allocation systems have been recently studied as alternative to traditional approaches. One of them is
Tycoon, a distributed market-based resource allocation system that is sponsored by HP and available to test and
download. Tycoon assures a fair assignment of resources among a set of jobs that demand CPU processing cycles. Is
interesting to additionally have the possibility to predict application execution time and budget needs. In the work
presented here we compute and apply performance models for applications executing in Tycoon. In the experimental
validation we obtained a high degree of certainty about deadlines and bidding requirements. Further development of
results obtained could contribute to provide service guaranties of Tycoon for Grid systems.
KEYWORDS
Market-based resource allocation, Grid, performance models.
1. INTRODUCTION
Resource allocation systems have been classified into non-economic approach and those that use economic
mechanisms. Markets mechanisms can provide additional solutions for resource allocation in Grids. In
(Shneidman, J. et al, 2005) key design issues are debated about the market approach for solving resource
allocation problems.
An interesting project sponsored by HP is Tycoon (Lai, K. et al, 2004a, Tycoon, 2005), a market based
distributed resource allocation system based on proportional share that implements auctions as the economic
mechanism. Tycoon is a prototype for managing CPU cycles. It uses Linux as developing platform and Xen
(Barham, P. et al, 2003, Xen, 2006) for virtualization.
The architecture of Tycoon has four components. The Service Location Service (SLS), Bank, Auctioneers
and Agents. The SLS is used by auctioneers (to advertise resources every 30’) and agents (to locate
resources). The Bank transfer funds from a client’s account to a provider’s account and makes use of signed
messages. There is an Auctioneer per node and it manages local resources with no information share
between auctioneers. Agents act in behalf of users and interpret user’s preferences and compute the bids on
the machines to maximize the user’s utility. HP offers to community the Bank service and SLS service in
tycoon-sls.hpl.hp.com and tycoon-bank.hpl.hp.com respectively.
In Tycoon users need to bid credits to achieve the execution of their jobs. One interesting question is, how
can we predict (or be sure) that deadline execution time requirements (for a given job) will be meet? And,
how can we compute the credits needed to bid on Tycoon in order to increase the number of transactions of
an application executed by a given time.
In this work we present a performance model and carry out fine grain experiments for seven scenarios by
profiling three kind of jobs (IO_CPU, IO and CPU). Finally, we validate our models against the measured
results.
2. PERFORMANCE MODEL
The basic workload components (request or transaction) for our experiments are generated by jobs which
focus on stressing: CPU, IO and a mix of IO and CPU. Even though these programs do not resemble the real
workload we think this approach give us significant information about Tycoon performance.
We present a predicting model which is applied in seven scenarios that corresponds to a equal number of job
execution in two competing virtual machines in Tycoon.
For this model we use the allocation function given in (Lai, K. et al, 2004b),
bi
t
r i = n −1 i
∑
j =0
bj
tj
R
(1)
where ri describes the proportion of resource R allocated to user i over a period P (10 seconds). The
auctioneer calculates the bid as bi/ti. For our experiments we left interval of t to default value with no changes
during all running time, hence we can simplify the previous formula to
(2)
from which we can obtain a degree of predictability for the amount of R that we can obtain by increasing (or
decreasing) the amount of credits.
Also we can obtain from (2) another function for prediction purposes of the bidding requirement, as
discussed in (Lai, K. et al, 2004b),
(3)
We apply operational analysis to express this value in a fine grain detail in order to estimate parameters
performance and compute an approximation for bidding the needed credits to meet specific requirements like
deadline execution time or transactions executed per unit of time.
3. EXPERIMENTS AND RESULTS
For experimentation Tycoon has enough auctioneers available to be used by clients, nevertheless we deploy
a resource provider in order to measure global CPU performance of guest operating systems running on
every virtual machine, as we are using Xen also we measure CPU of the privileged domain-0 in order to
calculate the overhead imposed for the guest OS running on it.
The resource provider node has a processor Pentium IV M 3.06, a hard disk with 60GB (4200 RPM, UltraATA/100) and network interface card (BroadBand 440x 10/100). The software used for the operating system
is Fedora Core 4 and for virtualization Xen 3 (2.6.16-xen3_86.1_fc4) . Tycoon client and auctioneer are
0.3.4p366 version.
We model our jobs as a set of consecutive request/transactions, no think time is modeled, and running time
(length) of the experiments is computed to be as close as possible to 30 seconds. The purpose is that jobs
behave as those that are intensive processing.
Our baseline experiments for the predicting model start with one credit on each virtual machine. The
scenarios that we measure in this work are shown in table 1:
Table 1. Scenarios and jobs executed on each VM
scenario
Virtual machine #1
Virtual machine #2
1
IO_CPU
CPU
2
CPU
IO_CPU
3
IO
CPU
4
CPU
IO
5
IO_CPU
IO_CPU
6
IO
IO
7
CPU
CPU
In order to apply the model we obtain the number of transactions, composite transactions C, and the
measurement interval T (accumTime) from our benchmark user application. Cpu utilization of each VM is
obtained with an accounting system tool (Xenmon). To compute transactions/requests processed per unit of
time we use.
X
job
=
C job
T job
(4)
On table 2, details of scenario number one are shown to discuss the approach followed to in the model.
Table 2. Measured and calculated values for scenario one
metric
Job IO_CPU (VM1)
Job CPU (VM2)
transactions
47
32
Composite transactions (Cjob)
235
128
accumTime (Tjob)
30.07 sec.
30.02 sec.
Throughput (Xjob)
7.82 tps
4.26 tps
cpu (mean)
48.00%
47.41%
Total cpu
95.41%
Dom-0ovh
4.13%
cpunorm (Ujob)
0.50
0.49
Service demand (Djob)
0.064
0.116
The utilization U (cpunorm) is computed to normalize cpu consumed by each virtual machine in order to isolate
the cpu overhead caused by privileged Domain-0. This is done in order to calculate accurate service demands
for each job running on every virtual machine.
Figure 1. Utilization on each VM
IO_CPU(VM1) and CPU(VM2)
100
90
80
Dom-0
60
50
VM1
VM2
40
Dom-31
30
20
10
time
31
33
25
27
29
19
21
23
11
13
15
17
0
0
2
4
6
8
cpu
70
We see in figure 1 the utilization U during the running experiment for scenario one. Notice the overhead
caused by Domain-0 which is quite small, additionally we can see that the Tycoon Auctioneer process (that is
running in this privileged Domain) incurs in little extra overhead every time (10 seconds) while it has to
recompute ri, see formula (1). Domain-31 is measured by the accounting tool and represents free cpu.
Now we proceed to calculate service demand on each virtual machine with.
D job =
U job
X job
(5)
with values DIO_CPU, TIO_CPU, XIO_CPU and DCPU, TCPU, XCPU we apply (2) for predicting ri by varying bi. Lets
discuss the approach for second virtual machine with DCPU and TCPU. Assuming that B=4 and user bids 1
credit to execute its job CPU bi =1, we obtain that ri=0.2 which is UCPU. From (5) we obtain that XCPU =
1.7162 tps, and finally from (4) we obtain that CCPU=51.521 composite transactions executed during 30.02
seconds. Here the CPU computed to be consumed by virtual machine two is 19.08%. Table 3 shows
predicted values with bi =1 and B from 1 to 10.
We ran seven experiments to obtain the performance models for each scenario. We did it by increasing
bidding bi (from 1 to 9). Credits in virtual machine two is constant and set equal to 1. In order to validate
them we run 56 additional experiments to compare measured results against analytical results.
Table 3. VM2 executing job CPU, decreasing bi (by increasing B)
ri
Xi
0.5
0.33
0.25
0.2
0.17
0.14
0.13
0.11
0.1
0.09
4.29
2.86
2.15
1.72
1.43
1.23
1.07
0.95
0.86
0.78
Di
0.12
0.12
0.12
0.12
0.12
0.12
0.12
0.12
0.12
0.12
bi
Ci
B
1
1
1
1
1
1
1
1
1
1
1
2
3
4
5
6
7
8
9
10
Ti
128.8 30.02
85.87 30.02
64.4 30.02
51.52 30.02
42.93 30.02
36.8 30.02
32.2 30.02
28.62 30.02
25.76 30.02
23.42 30.02
CPU
47.7
31.8
23.85
19.08
15.9
13.63
11.93
10.6
9.54
8.67
Table 4. Validation of model for scenario one
Virtual Machine 1
Throughput
Bids
bi
1
2
3
4
5
6
7
8
9
Measured
7.82
9.46
11.33
12.12
12.88
13.58
13.01
13.59
14.11
Model Error
7.77
-0.01
10.36
0.09
11.65
0.03
12.43
0.02
12.94
0
13.31
-0.02
13.59
0.04
13.81
0.02
13.98
-0.01
Mean error
0.0186
Virtual Machine 2
Throughput
Bids
bi
1
1
1
1
1
1
1
1
1
Measured
4.26
2.9
2.12
1.72
1.2
1.19
1.05
0.92
0.92
Model Error
4.29
0.01
2.86
-0.02
2.15
0.01
1.72
0
1.43
0.16
1.23
0.03
1.07
0.02
0.95
0.03
0.86
-0.07
Mean error
0.0201
In table 4 we can see that our performance model for scenario one give us a mean error of 1.86% for job
IO_CPU and a mean error of 2.01% for job CPU. Similar results were obtained for the rest of the scenarios.
For instance, scenario three give us a mean error of -0.91% for job IO and a mean error of 0.69% for job
CPU which is quite accurate. On the other hand, scenario six give us a mean error of -3.34% for job
IO(VM1) and 3.53 for job IO(VM2).
4. CONCLUSION
We have shown a performance model which allows predicting execution and bidding requirements in
Tycoon. These models have been applied in different scenarios and validated in several experiments. With
the results we obtained, users have better control on resource usage and budget of their applications.
Performance models are useful to capture fine grain behavior by profiling composite transactions for a given
application. We can see that results from the model predictions give us small mean errors for the seven
scenarios. Even though we think the predicting model is enough accurate, we believe that a longer
measurement interval will reduce these errors. In addition, future work includes more experiments with more
than two competing virtual machines. Tycoon with this performance models could be integrated as resource
provider with Grid systems where SLAs have to be meet by their resource providers.
ACKNOWLEDGEMENT
This work was supported in part by the Ministry of Education and Science of Spain under Contract TIN20065614-C03-01, and by the Mexican Ministry of Education under program PROMEP (PROgrama de
MEjoramiento del Profesorado).
REFERENCES
Barham, P. et al, 2003. Xen and the art of virtualization, Proceedings of the 19th ACM Symposium on Operating Systems
Principles, New York, USA.
Lai, K. et al, 2004a. Tycoon: A Distributed Market-based Resource Allocation Systems. Technical Report
oai:arXiv.org:cs/0412038, HP Labs.
Lai, K. et al, 2004b. Tycoon: an Implementation of a Distributed Market-Based Resource Allocation System, Technical
Report arXiv:cs.DC/0412038, HP Labs.
Shneidman, J. et al, 2005. Why Markets Could (But Don’t Currently) Solve Resource Allocation Problems in Systems”.
Proceedings of Tenth workshop on hot topics in operating systems, New Mexico, USA.
Tycoon , 2005. [online]. [Accessed 27th June 2006]. Available from World Wide Web: <http://tycoon.hpl.hp.com/>
Xen,
2006.
[online].
[Accessed
10th
July
2006].
Available
from
World
Wide
Web:
<http://www.cl.cam.ac.uk/research/srg/netos/xen/>