Besides managing the resources in the platform and ensuring the proper execution of the tasks on them, Computing Platforms have to provide the forecast of the temporal, energetic and monetary cost for the mobile device of running the task on its resources.
The three models for the Cloud Platform are very similar to the models used for the CPU and the OpenCL Platforms; however, two important considerations differentiate them from the ones described in sections 5.1 and 6.5. First, workers can directly fetch data values from other workers; therefore, the mobile device only needs to transfer those values that are not on the remote nodes. The second factor to consider is the heterogeneity of the resources managed by the platform. While the CPU and the OpenCL platforms considered all the processing elements of
7.3. COST FORECASTING
the platform to have the same features, the remote resources are likely to be different, especially when using nearby resources such as multiple laptops or servers.
The actual computation of the task does not incur any energetic expenditure for the mobile device since the energy dedicated to it is part of the remote resource consumption; hence, it has no impact on the battery lifetime. Regarding the price, computing services usually do not charge for the time that the user is actually computing on the resources, but instead, they charge according to the time that a user reserves them. For instance, Cloud providers charge the same amount for a VM instance whether it is actively computing or idle. Neither the energy nor the economic model considers the costs of executing the task; they only take into account the cost of the data transfers related to the task. Since workers prioritize obtaining the data from another worker, the mobile device has to send only those input values without remote locations. Applications can access any of the values created or updated by the task and transfer it back to the mobile; however, it is impossible to determine, at the moment of computing the forecasts, whether the mobile will fetch the value or not. Assuming a worst-case scenario, both models presume the mobile to bring back all the output of the task. Both models compute the total sizes of the amount of data to emit to and receive from the remote workers and respectively multiply them by the price and energy consumption for emitting and receiving one byte.
To estimate an end time for the task, the platform first needs to determine on which node the task will run. Given that the criteria to pick a resource is the earliest end time, the platform only needs to estimate the end time on each resource to find out on which one runs the task and return the corresponding forecast. As with the CPU and the OpenCL Platform, to compute the end time, the platform considers two aspects: the expected start time and the length of the execution. The heterogeneity of the resources managed by the platform complicates the forecasting of the temporal cost for the task since the platform has to consider a different behavior of each implementation on each node. For that purpose, the platform maintains the performance stats of each node in separated Implementation Profiles and uses the shortest average execution time of all the possible implementations of the task as the time required to compute the task on the node.
For estimating the start time of the task, the platform takes into account when the node has free resources to host the execution and when all the data is available on the node to launch it. For the resource availability, the platform just divides an estimation of the timespan to compute the workload assigned to the node sequentially by the number of CPU cores on it. Estimating a time for the obtention of the input data of the task requires knowing the creation moment of each datum and the timespan of the possible transfers from their producing node. To determine a datum availability on a node, the Cloud Platform not only stores the expected end time of the task producing the datum but also for each datum its expected obtention time on each node managed by the platform. Thus, while computing the time forecast, if a datum has a registered obtention time for the node, the platform uses that one; otherwise, it is necessary to estimate the obtention time. If that datum is expected to be on any other node part of the platform, the node
should fetch it from there immediately or upon its creation through the high-speed connecting the workers. The platform determines the transfer time using the size of the datum – obtained from the Core Profiles – and the network bandwidth – deduced from the profiles of previous executions. Otherwise, if the register has no node of the platform expecting to have the datum, the platform considers that the master node generates it; the node will fetch the value using the mobile network and the transfer time computed by the platform should reflect the lower network bandwidth. When the platform offloads the task, it registers for each output datum the expected end time for the task as the expected obtention time for the value on the node. For those input data values whose obtention time on the node is not registered yet, it registers the computed estimation. Figure 7.4 notates the described models.