COEFIFIENTE SÍSMICO VERTICAL, K

In this subsection, we define the model we use for the chapter. We describe various parameters of the tasks in terms of computation and network, from which we derive per task-based energy models.

2.1.1.1 Computation

Let fl _{represent the CPU frequency of the mobile device, and f}c _{the CPU frequency of the data}

center1. If the task runs in the data center, there’s an additional speedup ratio of r due to additional memory [45]. Consider a task T that takes c clock cycles to run, requiring τl _{= c/f}l _{seconds to}

execute locally. The time required to execute the task in the cloud is τc = τl· fl_/(rfc_{). We assume}

the data center has a fixed number of machines, represented by the capacity, C, each can only run one task at a time. We assume that tasks can be executed immediately after it arrives. In addition, the scheduling of tasks is non-preemptive, i.e. once the data center makes the commitment to schedule a task, the execution of the task cannot be interrupted and resume later.

2.1.1.2 Network

The mobile network is intrinsically unpredictable and hard to model. We resort to a simple model where the mobile client knows the average bandwidth of nb_{of its network. Assume that task T has}

a data size of ndbytes, then it takes τt= nd_/nb_{seconds to transmit the data over to the data center.}

1_{We use superscripts to denote the ”type” of a variable so that subscripts can be reserved for the numbering of} individuals

We assume that the data center has sufficient network bandwidth. Thus the offloading processes will not experience any bottleneck in data transmission.

2.1.1.3 Energy

We adopt a simple energy model where the mobile device operates in one of the three states: computing state with power Pc, transmitting state with power Ptr, and idle state with power Pi [45]. The energy for local execution is Pc_τl_{, the energy for transmission is P}tr_τt_{, and the energy}

spent waiting for remote execution results is Piτw, where τw ≥ τc_{is the waiting time. Notice that}

the waiting time can be longer than the time of execution.

One interesting fact reported by the authors of [33] is that the benefit from offloading grows more than linearly as computation size increases. It is due to the fact that larger energy savings will amortize the fixed ”start-up” cost of various components triggered by the code migrating process. For example, there are costs associated to power up the radio, to save program states, etc., which are a roughly fixed cost and do not grow with program sizes. We accommodate this aspect in our model by adopting a fixed term in the calculation of migration energy cost.

Tasks will be in one of the three states: successfully offloaded and executed in the cloud, offloaded yet not scheduled due to resource limits, and locally executed (without being offloaded). We denote the states by remote, offloaded, and local, respectively. The energy savings ∆E of different states are:

∆E =                El_{− E}c _{if remote} −Ec _{if offloaded} 0 if local (2.1) 2.1.1.4 Task

The final task model is listed in Table 2.1. We choose to consolidate the task parameters into a simpler abstraction consisting of two categories, time and energy. The table also shows how the parameters are derived, where the additional parameters involved (as we show in the following

Parameter Explanation Derivation

τl _{Local exec. time c/f}l

τc _{Cloud exec. time τ}l_fl_/(rfc₎

τt _{Transmission time n}d_/nb

El _{Local exec. energy P}c_τl

Ec _{Offload energy overhead P}tr_τt_{+ P}i_τw

tr _{Release time}

td Deadline

Table 2.1: Code offloading task parameters

section) are generated with reference to real-life models. Notice that for convenience we define tr _{to be the time when tasks can start execution in the cloud. The actual offload decision is made}

earlier. We further define a few variables that are useful in our algorithms and discussion. Benefit, b refers to the efficiency of energy saving of a task, i.e. b = ∆E0/τc_{. Since ∆E is not known in}

advance, we use the estimated energy savings, ∆E0 = El_{− E}c_{. Slack defined by t}d_{− t}r _{− τ}c_{, is}

the period that a task can afford to wait before its deadline is reached. We test our model in the simulation and it shows accordance with experimental results from the offloading frameworks [33] [34].

In building the system model, we carefully seek a balance between simplicity and fidelity of the model. The scheduling problem lies on an extremely simple abstraction, where only a single type of resources is studied. On the other hand, the model for data center often involves sophisticated modeling of CPU, memory, I/O, network, etc. [46]. To resolve the conflict, we rely on the following observations. First, tasks in offloading are more computation intensive than data- intensive, as demonstrated in the typical applications like a chess game, face recognition, etc [32]. Given the limited network bandwidth of cellular networks and energy constraints, only a relatively small amount of data can be offloaded (as compared to generic cloud applications). Thus CPU is more likely to be the single bottleneck in resource allocation. Second, task execution is not distributed among multiple machines. Researchers have shown that parallel execution does not improve the performance linearly with an increasing number of machines used [34]. Thus we

assume tasks will be running only in a single container (physical machine or VM, denoted by machinefor the rest of the chapter). Thus unlike the situation for modeling MapReduce tasks, the I/O bandwidth of machines in our case is not of much concern. Those observations justify our approach to attribute execution time cost only to computation and using the abstraction that each task runs on a single machine.