## 2 Materials and Methods  
So far, many scheduling algorithms been proposed for various application scenarios [12; 13; 14]. For example, in [12], the authors propose an energy-efficient adaptive resource scheduler architecture for providing real-time cloud services to Vehicular Clients. The main contribution of the proposed protocol is maximizing the overall communication-plus-computing energy efficiency while meeting the application-induced hard Quality of Service (QoS) [14] requirements on the minimum transmission rates, maximum delays, and delay jitters. In [14], the authors propose a joint computing-plus-communication optimization framework exploiting virtualization technologies to ensure users the QoS, to achieve maximum energy savings, and to attain green cloud computing goals in a fully distributed fashion. Basically, these proposed algorithms and architectures can help with rethinking the design of scheduling algorithms in depth. Generally, there are two types of scheduling algorithm can be provided based on the time of scheduling, namely, the real-time type and the batch type. Basically, the received tasks are immediately assigned to cloud server nodes in the real-time type. Conversely, in the batch type, the received tasks are accumulated for a period of time and subsequently dispatched to cloud server nodes. A scheduling algorithm of the batch type can obtain better performance than one of the real-time type. This is because the assignment results of all tasks can be considered in a batch-based scheduling algorithm [11; 15; 16]. So far, many scheduling algorithms [2; 9; 10; 11; 15; 17] have been proposed to dispatch the task to cloud server nodes in the cloud computing network, such as the Min-Min [9; 10; 15; 17], Max-Min [9; 15; 17], Suffrage [2; 9; 11; 17], and Max-Suffrage algorithms [2; 9; 15; 3]. However, these algorithms only consider the factor of the expected completion time (_ECT_) without considering the load status of the server node. Therefore, the performance is not as good as expected, and the minimum completion time cannot be obtained. For example, in the Min-Min algorithm, the task \(i\) with the minimum _ECT_ of the unassigned tasks \(T\) is called _min_ECT_. Subsequently, the task which has minimum _ECT_ can be elected and dispatched to corresponding server node. Then, the task which is newly matched is eliminated from a set \(T\) and the procedure is repeated until all tasks are dispatched. Under this circumstance, the workload will easy to unbalance while there are too many tasks waiting to be scheduled. In the Max-Min algorithm, the \(ECT\) is also to be used for dispatching tasks. Conversely, the task with overall maximum \(ECT\) in Max-Min algorithm is always to be selected to assign; thus, the overall \(ECT\) will be increased significantly [9; 15; 17]. Besides this, both of above algorithms easily cause higher-capacity server nodes to be assigned more tasks than lower-capacity server nodes. The workloads of cloud server nodes are unbalanced and inefficient. Therefore, an improvement algorithm, the Sufferage algorithm [1; 17; 18; 19], was proposed to reduce the workloads of the cloud server nodes. In the Sufferage algorithm, the Sufferage Value (\(SV\)), which is calculated by the second earliest \(ECT\) minus the earliest \(ECT\), is used as an estimated factor to dispatch the task. Then, the task which has largest \(SV\) value can be selected and dispatched to the corresponding cloud server node which has minimum \(ECT\). However, the Sufferage algorithm cannot obtain efficient performance when the number of waiting tasks is very large. Therefore, the Max-Sufferage algorithm [3], which is improved from the Sufferage algorithm, has three phases to solve the above problem. At first, the SV values of all tasks need to be calculated in the \(SV_{i}\) calculation phase. Subsequently, in the \(MSV_{i}\) calculation phase, the second earliest \(ECT\) of task \(i\) which has the maximum \(SV\) value will be elected as the Max-Sufferage Value (\(MSV\)) value.