{'fraction_non_alphanumeric': 0.025241984271022384, 'fraction_numerical': 0.004552329098608591, 'mean_word_length': 4.958457240695684, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Adaptive Scheduling for Efficient Execution of Dynamic Stream Workflows

Stream workflow application such as online anomaly detection or online traffic monitoring, integrates multiple streaming big data applications into data analysis pipeline. This application can be highly dynamic in nature, where the data velocity may change at runtime and therefore the resources should be managed overtime. To manage these changes, the orchestration of this application requires a dynamic execution environment and dynamic scheduling technique. For the former requirement, Multicloud environment is a visible solution to cope with the dynamic aspects of this workflow application. While for the latter requirement, dynamic scheduling technique not only need to adhere to end user's requirements in terms of data processing and deadline for decision making, and data stream sources location constraints, but also adjust provisioning and scheduling plan at runtime to cope with dynamic variations of stream data rates. Therefore, we propose a two-phase adaptive scheduling technique to efficiently schedule dynamic workflow application in Multicloud environment that can respond to changes in the velocity of data at runtime. The experimental results showed that the proposed technique is close to the lower bound and effective for different experiment scenarios.


I. INTRODUCTION
Several IoT applications and services such as smart cities, smart parking and smart traffic control, have evolved to cope with the demand of improving our lives [1] [2]. These applications are not monolithic application, but they contain a network of different analytical components which are composed in the form of a workflow to make better decisions. An example of this workflow is smart road traffic monitoring as a service of smart city services that utilizes the true power of connected vehicles in addition to roadside infrastructure (e.g. traffic lights, cameras) to create real-time view of road traffic conditions [3]. This type of workflow is also called stream workflow application and is becoming gradually viable for solving real-time data computation problems that are more complex.
Stream workflows are very different from traditional business and scientific workflows [4] [5] as they have to continuously process an infinite stream of data with each analytical component always in an active state. They can be more complex and involve heterogeneity, multiple data sources and multiple outputs. They also differ from streaming operator graphs (generated by Apache Storm or Flink for example) as the source of data for the whole operator graph is one and there is one end operator, thus operator graph is just a simplified case of stream workflow. Moreover, this workflow can be highly dynamic in nature, where the data velocity may change at runtime which reflects the load at given time, and therefore the resources should be managed overtime. Furthermore, the use of single cloud to execute this workflow could not meet user requirements due to the distribution of external data sources, thus Multicloud environment that consolidates multiple clouds can help in utilizing data locality by orchestrating analytical components included into data pipeline over different clouds; however, provisioning resources from different clouds while meeting user performance requirements is also a challenge. Combining these challenges and complexities with available heterogeneous compute resources that are available in cloud datacenters and users' quality of service requirements, managing the execution of such applications is a complex task.
In general, stream workflows have received less attention, but the importance of making real-time decisions by analysing streaming data is rising with IoT emergence. Most of existing research works focused on supporting the other type of big data processing which is batch processing. These works such as [6] [7] provided the ability to compose batch processing applications into pipeline to process static data at once and get final analytical insights by extending the capability of scientific workflow management systems. While the rest offered big data orchestrators (Apache YARN [8], Apache Mesos [9] and Amazon Lambda 1 ) that do not need to deal with the dynamism of stream workflow applications and meet real-time user requirements. Therefore, there are few scheduling algorithms in the literature that treat the scheduling problem of various streaming big data applications over cloud infrastructure.
Dealing with dynamic stream workflow application should be based on the fact that this workflow is an adaptive workflow application that serves the current-extra and future demands of changing real-time analytical requirements at runtime to make faster and better decisions.
To fill the gap of supporting dynamic scheduling under the variations of data stream rates, we design a new adaptive scheduling technique. This technique revises the scheduling plan of dynamic stream workflow application according to changes happen in the speed of data at runtime to always meet real-time analytical requirements with minimal execution cost. In other words, it is aimed at tackling data stream velocity fluctuations while maximizing performance efficiency, and all of that at minimal monetary cost. In summary, our contributions are: • Dynamic stream application model. • Two-phase adaptive scheduling technique that incorporates two advanced optimization algorithms (Random immigrants Genetic Algorithm (GA) and two-level Greedy algorithm) to efficiently execute dynamic stream workflows. This paper is structured as follows: Section II reviews the related works. Section III presents dynamic stream workflow requirements. The problem formulation is presented in Section IV. Section V presents the proposed scheduling technique whose performance is evaluated in Section VI. Section VII concludes the paper and highlights future improvements.

II. RELATED WORK
In this section, we present the comparisons with related works from three perspectives, which are application, modelling and methods/techniques. From application perspective, there are batch-oriented big data workflow (MapReduce workflow) and stream-oriented big data workflow (stream workflow). The focus of previous studies (such as J. Wang et al. [6] [7], F. Teng [10], Y. Wang and W. Shi [11], T. Shu and C.Q. Wu [12], and X. Zeng et al. [13] [14]) were mostly on MapReduce workflows and their executions in cloud computing infrastructure.
From modelling perspective, there are two stream processing models, which are data-flow graph with micro-batch processing model (i.e. discretized streaming model) and operator graph with continuous processing model. With discretized streaming model, streaming computations are performed on a series of small data batches called micro-batches. M. Zaharia et al. [15] followed this model and proposed a stream programming model named Discretized Streams (D-Streams). It brings together a series of Resilient Distributed Datasets (RDDs) and allows performing computations through various transformations. Apache Spark uses RDD data model and allows to perform stream computations on RDD to define data processing. While with continuous processing model, operator graph is used to model data pipeline, where each node in the graph is a long-lived operator. This operator carries-out stream computation on streams as they arrive and produces new stream. Stream-oriented big data platforms and services such as Apache Storm and IBM Streaming allow to build streaming operator graphs for performing real-time data processing. As streaming operator graphs are different from dynamic stream workflows in that the source of data for the whole operator graph is one and there is one end operator, a new model is needed for dynamic stream workflow, which involves heterogeneity, multiple data sources and outputs.
From scheduling perspective, scheduling methods and techniques in the literature use heuristic and/or meta-heuristic approaches for making decisions based on different scheduling criteria (such as deadline, execution cost and performance) in order to meet user-defined SLA requirements. Research works such as D. Sun [16], T. Buddhika et al. [17] and A.
Boek and F Werner [18] focused on scheduling data stream computations for performance and/or energy optimizations. Also, stream-oriented big data platforms and services such as Apache Storm and IBM Streaming allow to build streaming operator graphs to process data streams and produce final output stream. However, those research works and frameworks model stream workflow as a streaming operator graph. Since streaming operator graphs are different from dynamic stream workflows, the placement problem (i.e. scheduling problem) of dynamic stream workflows have different assumption and optimization goals. This problem considers the mapping of analytical components to multiple compute resources as well as the optimization goals include minimizing execution cost and improving performance without violating real-time user requirements.
In the same perspective, D. Sun and R. Huang [19] and D. Sun et al. [20] focused on online scheduling with guaranteed makespan and utilized single cloud as an execution environment for big data streaming application. These scheduling strategies/methods do not consider stream workflow as a network of streaming big data workflow applications (i.e. workflow of workflows). They also do not take into consideration the dynamic nature of this workflow and its unpredictable performance, the various real-time decision support requirements and the powerful capability of 'cloud of clouds' as a dynamic execution environment. In the same context but for scheduling big data processing jobs/tasks and workflow in geo-distributed clouds, L. Chen et al. [21] proposed fair job scheduler with the aim of reducing job completion time that relied on Apache Spark. Z. Hu et al. [22] proposed a new job scheduling method named Flutter, which aimed at reducing completion time and implemented in Apache Spark. H. Chen et al. [23] proposed task-duplication based real-time scheduling method to reduce completion and execution times. However, these scheduling methods are considered stream workflow as operator graph and have different optimization goals.
For scheduling techniques supported with big data application orchestrators, each one of them uses a different scheduling technique to map applications on cloud resources. Apache YARN uses a monolithic scheduler to map compute resources among competing applications in the cluster. Apache Mesos uses a dual-level scheduling mechanism called resource efforts. This mechanism provides resource offerings to a framework and lets this framework either to accept the offer or reject it if the offered resources do not meet its constraints and then waiting for the ones they do. Consequently, these orchestrators assume either that they do not need to meet realtime decision support requirements or are intended for big data workflows that have predictable performance [24]. Therefore, the scheduling mechanisms in those orchestrators consider big data workflow application as a static structure, so that they neglect the following: (1) dynamic nature of this application and its analytical components, (2) unpredictable performance of this workflow application, (3) real-time performance requirements defined by the owners of these workflows, (4) runtime changes and (5) the powerful capability of 'cloud of clouds' as a dynamic execution environment.
Accordingly, the scheduling techniques proposed in the aforementioned studies do not fit the composition needs of complex big data workflows. They also do not leverage the capability of Multicloud environment to cope with the dynamic aspects of these workflows. As a result, dynamic scheduling technique is needed for a stable and efficient execution of stream workflow over multiple cloud infrastructures that meets user real-time performance requirements and respond to the runtime changes in velocity of streaming data while reducing the overall execution cost.

III. DYNAMIC STREAM WORKFLOW APPLICATION AND ITS REQUIREMENT
Stream workflow application is a network of streaming big data applications (analytical components) that can be independently executed over cloud resources while maintaining data dependencies among them. It has three main characteristics that need be considered, which are continuous input data (from external and internal sources), continuous processing and continuous insights produced by end analytical components. Considering these characteristics, this application is a dynamic workflow, as the most dynamism form that occurs frequently is changing the velocity of streaming data for analytical components. The real use case for stream workflow application along with details of the requirements are provided in Appendix A.
In this workflow, the throughputs of services under the dynamic variations of input data rates should be maintained all the time. Moreover to achieving these throughputs, endto-end latency (response time) is crucial in stream workflow application. It is a time between receiving input data stream at a service and generating output stream that regards this stream. Ensuring low latency is required during the whole execution of stream workflow. It should be kept as low as possible or be bounded when it starts to increase whilst maintaining user specific throughput. Furthermore in this workflow, there are distributed data sources that inject their data streams into a data pipeline, thus data locality approach should be utilized by leveraging Multicloud environment. With this environment, we can avoid transferring large data to the corresponding resources over long-heal networks that is not only incurring high latency and execution cost, but also makes achieving realtime data analysis requirements more difficult. Additionally, each cloud in Multicloud environment offers different computing capabilities with different prices, so that changing the placement cloud for a service from one cloud to another is possible to reduce execution cost.
Consequently, the variables of dynamic stream workflow application are type of service, its data processing requirement, its data processing rate, data mode, the dynamic variations of input data rates and the dynamism of execution environment (i.e. Multicloud). As well, variables of the later involved bandwidth and latency among various cloud infrastructures. Overall, the requirements of both workflow application and real-time data analysis should be maintained while dealing with data stream velocity fluctuations and minimizing the monetary cost during the continuous execution of this application.

IV. PROBLEM MODELLING
Prior to introduce the problem modelling of stream workflow application, we list all the terminologies that will be used in this model in Table I.

A. Application Model
Stream workflow application can be represented as a Direct Acyclic Graph (DAG) with G = (S, EX, E). S represents a set of N services S = s 1 , s 2 , ..., s N , EX represents a set of P external sources EX = ex 1 , ex 2 , ..., ex P and E represents a set of M edges/links between external sources and services, and between services themselves E = e 1 , e 2 , ..., e M . Each edge, e m is represented as a tuple (ψ m , s m dest , m ), where ψ m denotes stream output source which is either ex m denotes external source or s m org denote origin service, s m dest denotes destination service and m denotes the percentage of data generated by ψ m that is routed towards s m dest .
Each particular external source EX p is represented as a tuple EX p = (Λ EXp ), where Λ EXp denotes the output data rate (data velocity) of this output source. Each particular service S n , is represented as a tuple S n = (M I Sn , λ Sn , γ Sn ), where M I Sn denotes the number of floating-point operations required to process one MB of incoming data (service data processing requirement) in MI/MB, λ Sn denotes the arrival rate of data streams generated by sources outside the application in MB/s (such as data streams generated by sensors) to be consumed by the service, and γ Sn denotes the proportion of data generated by the service based on input streams.
Notice that, given the nature of stream workflow applications, it is possible that data generated by one service can be sent to one or more services, or can be split among different services. Thus, for service S n , both parameters γ Sn and m (in edges where such service is origin service) are necessary to define the whole application. In addition, to process streams that coming at different speeds, the minimum stream unit per second (denoted as unitDPRate) is needed to be specified for the whole workflow application. Thus, each provisioned compute resource must process at least one unit per second, and of course, it can process multiple units per second according to its computing capacity.

B. System Model
The cloud system is modelled as a tuple W = (C, L, B, D). A set of G clouds in the Multicloud environment is denoted as C = c 1 , c 2 , ..., c G . L, B, and D denotes matrices containing respectively the latency (in seconds), the bandwidth (in MB/s), and the data transfer cost (in cents/MB or ¢/MB) between each of the pair of clouds in C.
Each cloud, c g is represented as a tuple (V M g , U g ), where V M g = vm g 1 , vm g 2 , ..., vm g K is a set of K virtual machines (compute resources) with different resource configurations deployed in c g , and U g = u g 1 , u g 2 , ..., u g H , u g h = (vm g org , vm g dest ), a set of H links that are part of the data center network topology.
Each VM deployed in the cloud, vm g k , is represented as a tuple (M IP S vm g k , ¢ vm g k ), where M IP S vm g k denotes floating-point operations computed by this VM according to its compute capacity per second and ¢ vm g k denotes the cost of provisioning such VM (in cents per second).
The data processing rate for S n if it is mapped to vm g k is denoted as ϕ g k and is calculated by dividing VM computing power by service unit data processing rate and service data processing requirement as follows: W here χ = unitDP Rate * M I Sn and M IP S vm g k ≥ χ As S n could be mapped to more than one VM to achieve user performance requirements, let pro(S n ) be the set of VMs that are provisioned from one cloud for service S n . The data processing rate for S n if it is mapped to VMs in pro(S n ) is the total data processing rates for S n on all provisioned VMs and is calculated as follows: In dynamic stream workflow application, the calculation of data processing rate for each service S n should be carriedout at runtime. This is because of the need to handle dynamic changes that result in varying the speed of input streams being injecting into this service. Thus, system should calculate this rate based on the updated input speed of a service after the occurrence of change request at runtime. Let inStream(S n ) denote the input stream of S n and is the total rate of incoming data from external sources and internal sources (i.e. parent services) based on data modes used to route such streams toward this service: The following data processing constraint of S n is maintained: Each service S n produces output stream as a result of computation. Let outStream(S n ) denote the output data stream for a service S n and is calculated by multiplying the total input rate of S n by output data proportion/percent as follows: The velocity of data for given external source may change at runtime, which leads to a direct impact either an increase or decrease on the velocity of data for each S n connected to this source. This change makes inStream(S n ) and outStream(S n ) be updated by the amount of data that being increased or decreased. Also, this change affects not only those services, but also has a subsequent change (i.e indirect impact) on the velocity of data for child services which have dependency-link with those services. Therefore, it is worth to note that the maximum number of velocity changes that can be sent at any instant of time is assumed to be one and such velocity change request (either increase or decrease request) is only happen via external source. Let ϑ Sn denote the amount of data stream (in MB/s) based on percentage change from original data rate that being increased or decreased to inStream(S n ) as P minDPUnits. In case of data velocity decrease, ϑ Sn should be 0 < ϑ Sn < inStream(S n ). The inStream(S n ) will be updated by adding or subtracting P minDPUnits and outStream(S n ) will be updated by multiplying the update total input rate of S n by output data proportion/percent as follows: inStream As well as the the decrease in velocity of data for S n leads to lower computing needs for maintaining the above data processing constraint, so that VM(s) that are not required will be deprovisioned. This results in cost reduction while meeting user real-time data processing requirements. While the increase in velocity of data leads to more computing demands to maintain the above data processing constraint for this high data rate, so that exVM(s) will be provisioned. Let exV M (S n ) be the set of new VMs that need to be provisioned from placement cloud of service S n to cope with the increase speed of data streams, and rmV M (S n ) be the set of VM(s) from pro(S n ) for service S n that will be terminated/deprovisioned in response to an decrease in the speed of data streams. Thus, pro(S n ) is updated periodically at runtime by provisioning new VM(s) in case of velocity increases or deprovisioning VM(s) from the existing ones to respond to velocity decreases as follows: pro(S n ), otherwise (no change) (7) As pro(S n ) is updated at runtime, the ϕ(S n ) is also updated, reflecting the new data processing rate for S n based on the updated pro(S n ).
Given the change in velocity of data that either increases or decreases data rate which leads to provision more VMs or deprovision existing VMs at runtime, the execution cost needs to be calculated frequently. For our problem here, the calculation basis for the total execution cost of dynamic stream workflow application is per second. If T is total time duration, for cost calculations it is divided into several one second intervals (i.e. T 1 , T 2 , ..., T i ).
Additionally, we assume that every data stream should be processed, as unprocessed data streams lead to incorrect results. We also assume that the order of stream portions should be maintained during the distributed among the corresponding compute resources. Based on these assumptions, we maintain user specific throughputs for all services and end-toend latency (response time) as low as possible or even bounded when it is being increased. Thus, the incoming data streams are processed as they arrive and the latency is maintained, which is a time from a stream being added to input queue until its emission from the service as output stream. Of course, in case of a child service receives two or more dependency streams from its parents services, the latency is from the time of the last stream being added to input queue until its emission from child service.
The cost of running VMs used by service S n to process incoming streams per second T i is denoted as ec(S n ) while the total cost of running all VMs used by all services to process incoming streams during period of time T is denoted as ExecCost(S,T). The ExecCost(S,T) is calculated by summing VM provisioning costs for all services for T time as follows: The ec(S n ) is calculated by totalling the costs of all VMs provisioned for S n per second as follows: The data transfer cost is based on the amount of data being moved, the cost of data transfer charged by cloud provider, and network bandwidth. In a dynamic workflow application, the velocity of data determines the speed of generation, processing and analysis of data, where both input and output data are moved among different clouds. As we mentioned before, the change in velocity of data affects the data transfer cost as increasing speed leads to an increase in the cost and vice versa, so that the cost calculation needs to be carried-out per second. Let cts(S n ) denote the cost of transferring streams for S n (including input streams from other services) per second, and CT Stream(S, T ) denote the total data transfer cost for the amount of data being moved for all services during the period of time T. The CT Stream(S, T ) is calculated by summing the costs of data transfer between services for T time as follows: CT Stream(S, T ) = Ti Sn cts(S n ) cents (10) The cts(S n ) is calculated by totalling the costs of data transfer performed by S n per second as follows:: , and parent(S n )is the set of parent services for service S n Overall, the objective function is to minimize the cost of executing the dynamic workflow without violating data dependences and real-time performance requirements while dealing with changes in speed of data at runtime: Eq. 12 is solved for minimization to generate cost-efficient scheduling plan for the execution of dynamic stream workflows. Considering services' data processing requirements and the variety of resources offered by multiple clouds, each service can be mapped to more than one resource in order to maintain its data processing constraint based on input data rate (refer to Eq. 2 and Eq. 4). If we relax such mapping constraint thus each service is mapped only to one resource (i.e. |pro(S n )| = 1), assuming that this resource is sufficient to meet service's data processing constraint (Eq. 4), this relaxed constraint makes the problem 0-1 assignment problem. In this problem, the assignment matrix M indicates that a service i is assigned to resource j if m ij = 1. This problem is well-known NP-hard [25]. Consequently, if we consider the mapping of a service to more than one resource (i.e. not relaxing mapping constraint) now, our problem is even harder than 0-1 assignment problem, so it is NP-hard problem. Moreover, our problem belongs to NP because if a feasible resource allocation solution is given, this solution can be tested in polynomial time using Algorithm 1. Accordingly, our problem is NP-complete problem.

V. PROPOSED ADAPTIVE SCHEDULING TECHNIQUE
As we discussed in the previous section, our scheduling problem is NP-complete problem. Thus, the problem's search spaces are complex, with large sets of VM offerings provided Algorithm 1 polynomial-time algorithm for checking the feasible solution 1: totalDPRate ← 0 2: for each service Sn in S do 3: for each VM vm g k from prov(Sn) do 4: totalDPRate = totalDPRate + ϕ(Sn, vm g k ) 5: end for 6: if totalDPRate < inStream(Sn) then 7: return false {this is not feasible solution} 8: end if 9: end for by various cloud infrastructures and many constraints that need to be fulfilled such as data dependencies, user-defined real-time performance, throughput and end-to-end latency. Indeed, the search space of finding candidate solution for efficient execution of dynamic stream workflow application rapidly increases with the size of problem. Furthermore, the fluctuation of data velocity overtime makes it necessary to re-explore the complex search space in order to find suboptimal solution as quick as possible, where exhaustive search for the optimal solution is not feasible. Consequently, th goal is to find near-optimal solution in the complex search space and revise it as fast as possible to tackle the changes in data velocity overtime without violating data dependences and realtime performance requirements while minimizing the total execution cost (Eq 12). As we cope with velocity change for this workflow application, the following are cases of changing in input stream rate of a service: • The speed of output stream of external source connected to this service is either increased or decreased. • The speed of output stream of parent service(s) connected to this service is either increased or decreased. This happen when the increase or decrease in the speed of stream propagated from parent services due to the increase or decrease in the speed of stream for connected external sources From the aforementioned goal, we have two challenges: (1) explore large search space to find candidate solution at deployment time and (2) revise this solution quickly and precisely with each velocity change request that occurs at runtime to locate sub-optimal solution to respond to such request. For the first challenge, genetic algorithm is useful algorithm in exploring complex search space to enable the practical implementation of optimizing problem; thus, the objective function of Eq. 12 can be considered as a fitness function of genetic algorithm. While for the second challenge, Greedy heuristic can be used to adopt deployment plan generated by genetic algorithm at runtime because it provides an immediate sub-optimal solution for tackling velocity change request as it needs a relatively small time to compute; thus, it can fulfil the need to make scheduling decision under time constraints, enabling the practical implementation of optimizing objective function at a given point. Accordingly, we propose a new adaptive scheduling technique for dynamic stream workflows.
The proposed technique is a two-phase dynamic workflow scheduling technique that incorporates two advanced optimization algorithms (i.e. Random immigrants Genetic Algorithm (GA) in Phase 1 and two-level Greedy algorithm in Phase 2) to effectively perform adaptive scheduling of dynamic stream workflow applications in Multicloud environment and intelligently response to changes happen at runtime (i.e. velocity changes) with minimal execution cost. The main design goal of this technique is to find the best placement plan for the services of given workflow application with minimal execution and data transfer costs and maintaining its efficiency after each adaptation to handle the velocity change requests. The flowchart of the proposed two-step scheduling technique is depicted in Figure 1. In the below paragraphs, we will discuss the two steps (and their sub-steps) of this technique. that exploiting the deployment flexibility provided by Multicloud environment.

First
Step − The proposed random immigrants GA is called to find the best global sub-optimal resource selection solution according to the original real-time performance requirements to improve scheduling efficiency. Once the stream workflow application is scheduled on provisioned resources and being executed, the proposed technique is moved to the next step to tackle dynamic changes in the velocity of data streams.

Second
Step − In this step, the proposed two-level Greedy algorithm is used to dynamically respond to the changes in the speed of data streams for services. This algorithm at first level determines the services whose their input data rates will be changed due to the received velocity change request. Then in second level, it finds the best resource provisioning/deprovisioning solution(s) that will be used to tackle these changes and revising scheduling plan (to provision new VMs or deprovision existing ones that are not needed any more).

A. GA with Random Immigrants Scheme
Traditional GA has a considerable problem, which is convergence that prevents genetic diversity of the population. Therefore, to avoid such problem and to enhance the genetic diversity of the population, random immigrants schema is used [26]. This schema retains diversity level of the population every generation via replacing a portion of candidate solutions in the current population with random candidate solutions called immigrants. Accordingly, we propose a random-based immigrants GA (GA for short) that is able to find sub-optimal resource selection solution for scheduling dynamic stream workflow application in Multicloud environment. It exploits data locality by selecting the most appropriate datacenter for each service, which leads to the reduction in both execution and data transfer costs. It generates the initial population randomly, and then evaluate the candidates and sort them in acceding order of fitness. During each generation, the elite candidate is selected and m random immigrants are generated then replaced the worst n candidates in the current population. Following the evaluation of m immigrants, the selection, crossover and mutation operators are applied. Finally, the elite candidate is added and the evolved population is evaluated and then sorted in acceding order of fitness before go to the next generation. The time complexity of this algorithm is presented in Table II. The Watchmaker framework for evolutionary computation [27] is used to implement this algorithm. O(gps 2 d) g the number of generations (as termination condition), p the size of population, s the length of candidate solution (number of services), u is maximum number of required minimum data processing units among services, v is number of VM offers in the placement cloud and d is maximum number of stream dependencies among services

B. Two-level Greedy Algorithm
We propose a new two-level greedy algorithm that uses Minimax with Alpha-Beta pruning method in game theory to minimize the maximum resource provisioning cost by finding the best resource selection solution for services that affected by data velocity changes. Minimax with Alpha-Beta pruning method is considered as a powerful searching and decision-making algorithm on game tree to find optimal/suboptimal result from possible choices. Thus, this method is used in our algorithm to find the best resources with the lowest provisioning cost at runtime to achieve the updated data processing rate for each service affected directly and indirectly by velocity change request. The direct effect happens when the service is connected to external source whose data velocity will be changed, while indirect effect occurs when the service is in the velocity change path).
Our proposed algorithm addresses the problem of ongoing resource scaling under the dynamic variations of data stream rates by managing resources overtime. This algorithm at first level determines the services whose their input data rates will be changed due to the received velocity change request. Then, at second level, it finds the best resource provisioning/deprovisioning solution(s) that will be used to revise scheduling plan. With the occurrence of velocity change request, it finds the best provisioning and scheduling solution, and then dynamically and quickly updating the scheduling plan to respond to this change request while reducing the overall provisioning cost. The pseudocode of the proposed two-level greedy algorithm is shown in Algorithm 2 and the time complexity analysis of this algorithm is presented in Table III. The pseudocode of two procedures that used in this algorithm to respond to velocity increase and decrease requests are shown in Algorithm 3 and Algorithm 4 respectively. The pseudocode of Minimax with Alpha and Beta algorithm that used in both procedures (Algorithm 3 and Algorithm 4) is shown in Algorithm 5. Algorithm 6 shows the pseudocode of evaluation function used in Algorithm 5. if velocity change request is increase request then 7: Velocity Increase Req Proc(Sn, min, max, depth) 8: else 9: Velocity Decrease Req Proc(Sn, min, max, depth) 10: end if 11: end for Algorithm 3 Velocity Increase Req Proc(S n ,min,max,depth) 1: reqU nits ← 0 2: unitM IP S ← M I Sn * unitDP Rate 3: avalV ms ← get VM offers from service placement cloud 4: avalV ms = avalV ms − {x ∈ V M g |M IP Sx < unitM IP S} 5: extraAchievedU nits ← ϕ(Sn, pro(Sn))/minDRRate − (inStream(Sn) * M I Sn )/unitM IP S 6: incRate ← get data rate increases over service input rate 7: reqU nits ← get number of units required based on incRate 8: reqU nits ← reqU nits − extraAchievedU nits 9: nodes ← create tree nodes for avalVms list 10: while reqU nits > 0 do 11: shuffle nodes and construct tree with specified depth 12: root ← get root of constrcuted tree 13: best ← Minimax AlphaBeta(depth, true, root, min, max) {best node for VM selected} 14: V Prior processing the velocity change request, the proposed technique finds the ids of service affected by this request directly or indirectly (Algorithm 2 Line 4). Then, for each service affected, it finds the best provisioning or deprovisioning solution based on the type of velocity change request. If the request is velocity increase request (Algorithm 2 Line 6), it calls Algorithm 3 to get VM offers of service placement cloud and then finding the extra minDPUnits that are achieved by the current provisioned VMs in accordance to service input data rate. Next, such algorithm calculates the number of Algorithm 4 Velocity Decrease Req Proc(S n ,min,max,depth) 1: redU nits ← 0 2: unitM IP S ← M I Sn * unitDP Rate 3: SPVMs ← pro(Sn) 4: extraAchievedU nits ← ϕ(Sn, pro(Sn))/minDRRate − (inStream(Sn) * M I Sn )/unitM IP S 5: decRate ← get data rate decreases from service input rate 6: redU nits ← get number of minDPUnits based on decRate 7: redU nits ← redU nits + extraAchievedU nits 8: while redU nits > 0 do 9: remove VM(s) from SPVMs achieved units > redU nits 10: if SPVMs is empty then 11: return {no provisioned VM can be deprovisioned} 12: end if 13: construct tree nodes from SPVMs list with specified depth 14: root ← the root of constrcuted tree 15: best ← Minimax AlphaBeta(depth, true, root, min, max) 16: V

12:
node.value ← cost 13: end if 14: return node minDPUnits required for data rate being increased over service input data and then deducting from this number the extra achieved units. After that, it calls Algorithm 5 several times to finds best VM(s) to provision until achieving the required units. While, with velocity decrease request (Algorithm 2 Line 8), it calls Algorithm 4 to get the list of VMs provisioned for a service and then finding the extra minDPUnits that are achieved by these VMs based on service input data rate. Next, such algorithm calculates the number of minDPUnits based on the data rate being decreased from service input data, and then increasing this number by extra achieved units. Next, it removes those VMs from the list of provisioned VMs where their powers achieved units greater than the number of minDPunits that will be removed. The remaining VMs in this list will be used to find the best VM to deprovision using 5.
Each run of the game finds the best VM to provision it in case of velocity increases or to deprovision it in case of velocity decreases. Since multiple VMs may be needed to achieve the updated data processing rate or may be released in response of decreasing the velocity, the game will be repeated to produce the best solution. For each VM selected, the number of minimum data processing units achieved based on the computing power of this VM in one game is deducted from the total required units (i.e. reqUnits) in case of velocity increases or from total reduced units (i.e. redUnits) in case of velocity decreases.
O(sub m ) s number of services, u is maximum number of required minimum data processing units among services, b is branching factor and m is maximum depth of the tree

VI. EXPERIMENTS AND DISCUSSION
A. Experiment Methodology 1) Configuration of Workflow Application: The four wellknown workflow structures from various domains are Montage in Astronomy, Inspiral in Astrophysics, Epigenomics in Bioinformatics and Cybershake in Earthquake science. These workflows operate on static data inputs and produce outputs. To simulate stream workflow applications, it is possible to use these workflow structures to achieve that by considering each job as a service and the flow of data to be streams of data coming from external and internal sources rather than static files.
In addition, a set of extra parameter configurations is required for those workflow structures to simulate stream workflow applications. These parameter configurations include data processing requirements of services, data rates of external sources, types of services, modes of data, placement datacenter (in case of unmovable service) and output data rates of services. As a result, different stream workflow applications can be modelled using the aforementioned workflow structures (Montage, Inspiral, Epigenomics and CyberShake) by simulating them in these workflow applications for our experiments. For each workflow structure, three different sizes are used (small, medium and large). Therefore, 12 real workflow applications are modelled for our experiments, which are Montage 25, Inspiral 30, Epigenomics 24, CyberShake 30, Montage 50, Inspiral 50, Epigenomics 46, CyberShake 50, Montage 100, Inspiral 100, Epigenomics 100, CyberShake 100.
2) Multicloud Environment: To form a Multicloud environment for our experiments, we model three different cloud system providers, namely (Amazon EC2 [28], Google Cloud Engine [29], and Microsoft Azure [30]). Each cloud system has different VM configurations that chosen from pre-defined machine types offered by this cloud provider. The details of computing power rating being used and different VM configurations offered by those clouds are provided in Appendix B.
In addition, to model boot time (startup time) for each VM configuration in the modelled clouds, we use average range of VM startup time defined in [31]. For each modelled cloud, we generate random numbers from the defined range and then assign these numbers to its VM configurations.
3) Configuration of Data Velocity: To model the amount of data that is being increasing or decreasing in velocity change request for one external source, we utilised future data rates given in Gartner foreseen [32] which specifies one connected vehicle will generate as much as 25GB/hour of data, equivalent to 8MB/s. By considering this value as the average data rate of external source in workflow application, we create different percentage ranges for modelling the increase and decrease in data velocity. For velocity increase, we model the value of increase in data velocity as a percentage that is increased from current data rate. We model the data velocity decrease as percentage of decrease in the current data rate. Table IV lists the percentages of change to increase data velocity. Table  V shows change percentages to decrease data velocity. It is worth to note that as there is a minimum limit for stream unit, the change value will be approximated/rounded to the nearest given minDPUnit. As an instance, if the minimum stream unit per second is 1MB/s and the 65% increase in data velocity from 5MB/s as original data rate is chosen randomly, the approximation will be applied on the change value (3.25MB/s) to be 3MB/s (i.e. the nearest value based on the specified minDPUnit) so that the new data rate will be 8MB/s.

4) Workflow and Simulation Parameters:
To run our experiments, we need to configure a set of parameters for both workflow application and simulator. These parameters and their values are fixed for all scenarios and listed in Table  VI. For external data source rate, the value considered is from the data velocity configuration discussed in the previous subsection. For network bandwidth and latency for ingress and egress traffic, we conducted TCP bandwidth and latency tests between different zones of Nectar Cloud 2 and considered the medium range from obtained results. For the cost of data transfer, we find the minimum and maximum data transfer costs between modelled clouds, and then use the created medium range to obtain values. Service data processing requirement represents the complexity of computation that carried-out by this service, which varies from simple (20 MI/MB) to complex (4000 MI/MB) aggregation functions. For the value of this requirement, we consider the created medium range. 5) Experimental Scenarios: Our experimental evaluations for efficiency and performance of the proposed technique are described in the below paragraphes: Comparison with baseline, GA and lower bound (Evaluation 1) − Study and compare the proposed adaptive scheduling technique (GA + Two-level greedy algorithm) in finding the best resource provisioning solution and adapting scheduling plan in response to velocity increases/decreases with competitors (baseline algorithm and random-based immigrants GA scheme) and lower bound. This comparison in term of the execution cost of different workflow applications for 3 minutes simulation time. A realistic baseline algorithm is created for our problem that does not need to use any heuristic. It finds VM with the highest computing power and then provisioning it to respond to velocity increase requests, while with velocity decrease requests, it deprovisions one or more VMs from the available VMs to respond to these requests. The aim of comparison with baseline algorithm is to appreciate the necessity of our proposed technique to find the best resource provisioning solution and adapting the scheduling plan in response to velocity increases/decreases. The comparison with GA schema is aimed at evaluating the proposed technique with another meta-heuristic algorithm that is widely used in workflow scheduling research works in order to further proof its efficiency. Furthermore, the comparison with lower bound is to show that the complicated heuristic is necessary to approach the lower bound as well as to evaluate how the proposed technique is far from lower bound. In lower bound, we have relaxed many constraints. The first constraint is service's datacenter placement constraint and the second one is VM provisioning constraint (by selecting the cheapest VM across all datacenter VM offers). The third constraint is data transfer cost (by using a lower cost value from the specified range). The last constraint is network bandwidth constraint (by using a lower bandwidth from the specified range which leads to reduction in data transfer cost by transferring less data). Then for each service, the cheapest VM from the placement cloud of this service is provisioned as many as is required to achieve the specified data processing rate. After that, the total execution cost (provisioning cost + data transfer cost) is calculated using Equation 12 during the period of time T. In this comparison, we consider the results obtained from lower bound as the base values.
Guaranteeing processing speed for execution time (Evaluation 2) − Study the efficiency of the proposed adaptive scheduling technique in guaranteeing processing speed required with different workflow applications under different velocity changes. This evaluation aims to show the data processing constraint is satisfying at all time with changing data velocity. The baseline here to achieve real-time userdefined requirements and end-to-end execution time is that the computing power available should be sufficient to process all incoming data without data loss. In other words, the computing capacity should be grater than or equal the velocity of incoming data at runtime. Thus, the sufficient computing capacity should be always maintained while the velocity of data increases or decreases at runtime. The experimental results will be collected before the end of simulation due to at that time all velocity changes have been made and handled by the proposed technique. This ensures the efficiency of the proposed technique to adopt scheduling plan in respond to velocity change request at runtime while guaranteeing processing speed required to achieve end-to-end execution time.
Efficiency of velocity change (Evaluation 3) − Study and compare the proposed adaptive scheduling technique with random-based immigrants GA scheme (GA for short) based on performance matrix presented in Figure 2 for performing dynamic scheduling at runtime. The aim of this evaluation is to determine how our proposed technique is effective in satisfying quality of service. This comparison is in term of the quality of solution for the revised scheduling plan, which includes solution cost (provisioning + data transfer cost per second) after the data velocity change request is applied, and the number of changes applied on the current scheduling plan to respond to this change request. The GA responses to each velocity change request by generating a totally new scheduling plan, which serves as a revised plan to replace the old one, while the proposed technique revises the current scheduling plan. When GA applied those VMs in the new plan that exist in old plan are excluded to avoid VM duplication. By doing so, only VMs in the new plan that are not exist in the old plan will be provisioned and those VMs in old plan that are not part of the new plan will be deprovisioned. Therefore, the number of changes include the changes in provisioning plan (for new VMs that are not in the old plan) and deprovisioning In aforementioned scenarios, data rate of each external source in workflow application is set to be 5MB/s with velocity-increase experiment or 10 MB/s with velocitydecrease experiment at the beginning of execution. As velocity change requests being sent, the data rate of chosen external sources will be increased or decreased according to the conducted experiment.
By comparing the total execution costs of all workflow applications obtained from proposed technique with the lower bound of total execution costs for these applications, we can evaluate the efficiency of the proposed technique in finding the best solution either resource provisioning or deprovisioning solution in response to velocity increases or decreases. In addition, comparing and evaluating the quality of solution for the proposed technique with GA allows to evaluate the performance of the proposed technique in relative to the performance of GA.

B. Experimental Results
To evaluate the efficiency and performance of the proposed technique, we conduct our experiments in simulation environment. This is because we need a controllable and repeatable environment to configure the parameters of each experiment scenario, and then compare the results obtained from the proposed technique with those from competitors under the same environment conditions. In real environment, some parameters like network bandwidth and latency cannot be controlled, making environment conditions are changing with each execution of workflow application. Thus, conducting our experiments in a real environment will produce inconsistent evaluation results, where these results cannot be used to assess the efficiency of proposed technique and the quality of solution produced to respond to data velocity change requests at runtime. Accordingly, we conduct our experiments using IoTSim-Stream [33], our simulation toolkit for modelling and simulating stream workflow applications in Multicloud environments.
The experimental scenarios are performed in simulation environment (by using IoTSim-Stream) on a Nectar Cloud virtual machine that had 8 vCPUs, 32GB of RAM memory and running Ubuntu 16.04.1 LTS, and the experimental results are collected. Since genetic algorithm is used in our proposed technique, each experimental scenario runs ten times, and the 1) Evaluation 1: Results: We conducted experiments to record total execution cost achieved by proposed technique and the competitors (Baseline, GA and Lower Bound) for modelled workflow applications under different ranges of velocity increase and decrease. As the experimental results for the first evaluation showed that the total execution costs of modelled workflow structures under different velocity change ranges (low, medium and high) for both velocity-increase and velocity-decrease have not changed significantly, we only present those results for medium range of velocity change. Figure 3 and 4 depict the total execution costs of modelled workflow applications under medium range of velocity increase and decrease that achieved by baseline algorithm, GA, proposed technique and lower bound. From these results, our analysis and findings are: • With various workflow applications, the proposed technique is efficient in finding the best solution to quickly respond to velocity change requests and then dynamically updating the current scheduling plan. The results of total execution cost obtained by the proposed technique compete the results obtained from both baseline and GA, and are close to the results of lower bound with most workflow structures. The reason behind that is the proposed technique uses GA at first phase for exploiting data locality to find near-optimal placement and scheduling plan, which reduces resource provisioning and data transfer costs, and then in the second phase, it uses greedy heuristic to find the best provisioning plan that reduces the provisioning cost as much as possible to respond to any velocity change request. • The cost resulting form the proposed technique is a maximum of 32% of the cost generated by lower bound under medium velocity change. The reason for this difference is due to the structure of workflow may lead to process less data, so that the provisioning cost reduction factor contributes more to the total execution cost. Based on that, lower bound produces unachievable results as VM provisioning constraint is relaxed, while the proposed technique maintains this constraint. • As data velocity increases from low to high range, the total execution cost for modelled workflow applications is slightly increased. The reason behind that is the proposed technique is able to revise the current plan to cope with velocity increase changes with minimal cost, leading to cost reduction even with high velocity of data. • The proposed technique is an adequate and practical dynamic scheduling method with competent accuracy. This is because it takes all the defined constraints into consideration while meeting user real-time performance requirements and reducing the overall execution cost with different workflows.
2) Evaluation 2: Results: We conducted experiments to record total input data rate (in MB/s) and total processing speed (in MB/s) achieved by proposed technique for modelled workflow applications under different ranges of velocity increase and decrease. From the results obtained, we present here those results for medium range of velocity increase and decrease since these results are enough to reach to the conclusion. Figure 5 and Figure 6 show the experimental results achieved by the proposed technique in term of total input rate and total processing speed. From the presented results, it is clear that the proposed technique always guarantee processing speed to process incoming data with all workflow application. Even more, it also has some extra computing power to handle increase in data velocity with immediate response and without the need to reschedule the execution plan.
3) Evaluation 3: Results: We conducted experiments to collect solution cost and number of changes achieved by proposed technique and GA for modelled workflow applications under different ranges of velocity increase and decrease. It is worth to note that we do not need to conduct experiments to record end-to-end latency, since our assumption in problem modelling is that every data stream arrives will be processed as soon as the dependency is achieved. Moreover, we do not need to conduct experiments to collect execution time required to respond to velocity change request because of the conclusion is straightforward. In regards to the computational time for velocity increase request, the straightforward conclusion is that GA needs more time to generate a new scheduling plan to repose to this request, while the proposed technique fastly revises the current scheduling plan by replying on the twolevel greedy algorithm for dynamic scheduling. In the favor of the velocity decrease request, the computational time needed for proposed technique to respond to this request is negligible since it just needs to deprovision the unnecessary VMs while GA needs to generate a new scheduling plan, so that it is far-fetched for GA to compete in that.
We present here the key important results from the second evaluation experiments. The experimental results for medium range of velocity changes (including both velocity increase and decrease requests) are only provided due to space reason. These results are enough to reach to the conclusion. Figure 7 and Figure 8 show the experimental results achieved by the proposed technique in comparison to GA in term of solution cost and number of changes required to revise the current scheduling plan. From the presented results, the following are our analysis and findings: • In term of execution cost, GA with each request tries to find sub-optimal solution by generating a new plan whilst the proposed technique just revises the current plan quickly, which may not lead to sub-optimal solution. • In term of the number of changes for a velocity request, the proposed technique responds to this request by quickly adjusting the current scheduling plan instead of generating a completely new scheduling plan, which is usually required a limited number of VM changes. In contrast, GA generates a new scheduling plan in both velocity changes, which is not only incurring more computational time but also requires a lot of VM changes to deprovision those VMs that are not in the new plan and to provision those that are in the new plan. To maintain the continuity of processing incoming streams at current data rates, unneeded VMs from the old plan This causes further overhead in execution time and cost more as both new VMs and the current VMs (that will be deprovisioned later on) are remaining in resource pool. Moreover, this also incurs more processing delays for upcoming streams when velocity change is increase request or more provisioning cost when the change is decrease request. • From Figure 7b and Figure 8b, we can notice that the most performance gains is achieved by Inspiral 100. The reason behind that is the structure of this workflow processes huge amount of data compared with other workflows, resulting more computing powers are required. Thus, generating a new plan is too expensive and incurring large number of changes, while revising the existing plan incurs small number of changes that leads to huge performance gains. • Based on the presented performance matrix (Figure 2), the proposed technique achieved a competent performance with high quality of solution besides good execution cost compared to GA with most workflows, non-competitive number of changes required to revise the scheduling plan, and little or negligible execution time. Thus, the proposed technique outforms GA with different workflow structures.

VII. CONCLUSION AND FUTURE WORK
In this paper, we considered the scheduling problem of dynamic stream workflow application on various Cloud infrastructures. These infrastructures forming a Multicloud environment, which becomes the dynamic execution environment for these applications. To this end, we proposed a new dynamic scheduling and provisioning technique that incorporates GA and two-level greedy algorithm to efficiently schedule dynamic stream workflow application in Multicloud environment while meeting real time user performance constraints under velocity changes with minimal execution cost. The experimental results showed that the proposed technique outperformed competitors (baseline and genetic algorithms) in responding to data velocity changes at runtime while reducing the total execution cost for all modelled workflow applications under various data velocity ranges. It also close to from lower bound.
For future study, this paper reveals two new directions to enhance the performance and capability of the proposed dynamic scheduling technique. The first direction is aiming to parallelise Minimax with Alpha-Beta pruning algorithm to reduce running cost and achieve speedup. The second direction is to support more dynamism forms for stream workflow applications such as application structure and real-time data processing requirement, where coping with these changes at runtime enables the full dynamic support.

A. Real Use Case for Dynamic Stream Workflow
A real use case for big data streaming workflow application that shows the need of real-time analytics and workflow orchestration in the next era of technologies, consider connected vehicles in smart cities. Since the traffic is strained with the continued increase of the number of vehicles and population, the smart road traffic monitoring as a service of smart city services can utilize the true power of IoT connected vehicles in addition to roadside infrastructure (e.g. traffic lights, cameras). Collecting and analysing the streaming data generated by these vehicles allow to create real-time view of road traffic and incidents. Figure 9 depicts streaming data pipeline for realtime view of road traffic in smart city. This pipeline represents a dynamic stream workflow application, which is a network of streaming analytical components. Each analytical component can be seen as a service because it can independently execute over any virtual resources, even though data dependencies among services should be maintained.
In the presented workflow application, streaming data generated by connected vehicles on the road as sensor data is injected into vehicle detection service to detect the presence of vehicles in real-time. This service produces continuous output streams that are partitioned between two services for applying specific calculation, and classifying and aggregating vehicle data. The information of movement flow based on vehicle Figure 9: Dynamic stream workflow application example speed and distance as a result of continuous computations is further analysed by roadside data analysis and traffic analysis services. Based on this movement flow and sensor data coming from traffic lights and cameras, the roadside data analysis service produces real-time information about traffic density, which gives the opportunity for adjusting traffic patterns. Also, the traffic analysis service generates in-depth real-time analytics for traffic patterns and conditions by processing and analysing two data stream inputs, the movement flow information and the aggregated vehicle data. These analytics as output streams are injected into traffic controlling service for processing to improve traffic modelling, alert road users and authorities about traffic events and predict the current weather. In this application, the most dynamic form that occurs frequently is changing the velocity of streaming data for services. This is because the smart city is dynamic environment and the speed of streaming data is changing greatly based on time or traffic alert. Thus, the load at given time determines the required resources for computing. Thus, dynamic scaling and elastic of road traffic monitoring service application should be treated carefully to achieve real-time performance requirements under varying of data rates.
A service in the presented workflow has data processing requirement (representing the complexity of computation) and data processing rate (representing the amount of streams processed based on the speed of incoming streams). It can be either unmovable or movable. Unmovable service is a service that receives large amount of data that needs to be processed locally to avoid the time and cost of transferring data) such as vehicle detection service. Movable is a service that receives small working streams that can be transferred with low communication overhead of data transmission such as speed & distance calculation service. Thus, with unmovable service, the data locality is applied to push service to the location of data while with movable service, placement optimization approach is applied to exploit the deployment flexibility.
The execution of the presented workflow is continuous. This means every service (e.g. roadside data analysis) receives continuous input streams from external source(s) (e.g. traffic light and camera) and/or internal source(s) (i.e. parent service(s) (e.g. speed and distance calculation), processes them continuously as they arrive and generate continuous output streams as the results of computations (e.g. pre-processed vehicle information), which routed towards one or more child services. The end service(s) such as traffic modelling generates the continuous output results for the execution of this workflow. In term of data mode that being used to route streams toward one or more child services, there are two modes: replica and partition. With replica mode, the output stream of parent service is replicated on child service(s). While with partition mode, the output stream of parent service is partitioned into portions based on the pre-defined partition percentages and then each portion is routed to the corresponding child service.

B. Modelled Clouds and their VM Configurations
To form a Multicloud environment for our experiments, we model three different cloud system providers, namely (Amazon EC2 [28], Google Cloud Engine [29], and Microsoft Azure [30]). Each cloud system has different VM configurations that chosen from pre-defined machine types offered by this cloud provider. Table VII show the configurations of VM for modelled clouds. As IoTSim-Stream [33], our proposed simulator that built on top of CloudSim to execute stream workflow applications in Multicloud environments, is used to run our experiments, the same computing power rating is applied. In CloudSim [34], MIPS rating is used to represent CPU unit, where the capacity of VM instance is represented by the total MIPS assigned to such instance based on the assigned value of MIPS rating multiplied by the number of assigned CPU cores (Processing Elements (PEs) in CloudSim term). Hence, the processing power of each VM instance offered by the modelled cloud is converted to the corresponding MIPS value.