WO2018013023A1

WO2018013023A1 - A server and method performed thereby for determining a frequency and voltage of one or more processors of the server

Info

Publication number: WO2018013023A1
Application number: PCT/SE2016/050721
Authority: WO
Inventors: Catalin Meirosu; Tereza Cristina CARVALHO; Rosangela DE FATIMA PEREIRA; Raquel MACHADO SOUSA; Bruno Bastos RODRIGUES; Marco Antonio TORREZ ROJAS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ); Ericsson Telecomunicacoes S.A,
Priority date: 2016-07-15
Filing date: 2016-07-15
Publication date: 2018-01-18
Also published as: BR112016021103A2

Abstract

A server 300, 400 and a method 100 performed thereby for determining a frequency and voltage of one or more processors of the server. The server supports Dynamic Voltage and Frequency Scaling, DVFS, and the server runs one or more virtual machines. The method 100 comprises receiving 110 incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; buffering 120 the received one or more packets; and predicting 30 amount of compute resource utilisation associated with the buffered one or more packets. The method also comprises determining 140 voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and releasing 150 the stored one or more packets to the one or more processor based on the predicted amount of compute resource utilisation and the determined voltage and frequency.

Description

A SERVER AND METHOD PERFORMED THEREBY FOR DETERMINING A FREQUENCY AND VOLTAGE OF ONE OR MORE PROCESSORS OF THE

SERVER

Technical field

[0001 ] The present disclosure relates to energy management of a server supporting Dynamic Voltage and Frequency Scaling, DVFS, wherein the server runs one or more virtual machines.

Background

[0002] Dynamic Voltage and Frequency Scaling, DVFS, is a generic name for a host of techniques that change the voltage and operating frequency of a processor in order to reduce the energy consumption when the workload on the processor is less than 100%. There are many techniques that were developed in this category, both in academia and industry.

[0003] Virtual Network Functions, VNFs, are applications specific to

telecommunications networks, executed on a cloud platform. For a significant category (such as firewalls, deep packet inspection functions, routers, etc.) a relationship may be determined between the incoming network traffic and the workload that this one induces on a processor.

[0004] Modulating DVFS in response to network traffic has been presented. It proposes a system that obtains packet inter-arrival rates and feeds this information to a DVFS governor. Given a certain packet inter-arrival rate, the system devises the optimal operation parameters for that rate. A similar solution was proposed for routers (and characterised in a virtual router environment). Such approaches may save energy as a simple reaction to the network traffic. Given the transition times to and from energy efficient states (10us - 100ms typical, depending on the processor and specific state), such approaches are clearly suboptimal Summary

[0005] The object is to obviate at least some of the problems outlined above. In particular, it is an object to provide a server and a method performed thereby for determining a frequency and voltage of one or more processors of the server, wherein the server supports DVFS and the server runs one or more virtual machines. These objects and others may be obtained by providing a server and a method performed by a server according to the independent claims attached below.

[0006] According to an aspect, a method performed by a server for determining a frequency and voltage of one or more processors of the server is provided. The server supports DVFS and the server runs one or more virtual machines. The method comprises receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; buffering the received one or more packets; and predicting amount of compute resource utilisation associated with the buffered one or more packets. The method also comprises determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and releasing the stored one or more packets to the one or more processor based on the predicted amount of compute resource utilisation and the determined voltage and frequency.

[0007] According to an aspect, a server for determining a frequency and voltage of one or more processors of the server is provided. The server supports DVFS and the server runs one or more virtual machines. The server is configured for receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; buffering the received one or more packets; and predicting amount of compute resource utilisation associated with the buffered one or more packets. The is further configured for determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and releasing the stored one or more packets to the one or more processor based on the predicted amount of compute resource utilisation and the determined voltage and frequency. [0008] The server and the method performed thereby have several advantages. One possible advantage is that the power consumption of a processor in a server (or datacentre) may be reduced. This may reduce operation expenditures and increase for environmental friendliness of the server. Another possible advantage is that constraints related to service time may be maintained, thus providing transparent trade-offs to the operator in this respect. Still a further possible advantage is that control and overview of the resources used in the network for a given service or application is enabled. Yet a possible advantage is that correlations may be found and knowledge may be created or obtained to make recommendations that enable the optimisation of resources allocated to cloud computing.

Brief description of drawings

[0009] Embodiments will now be described in more detail in relation to the accompanying drawings, in which:

[00010] Figure 1 a is a flowchart of a method performed by a server for

determining a frequency and voltage of one or more processors of the server, according to an exemplifying embodiment.

[0001 1 ] Figure 1 b is a flowchart of a method performed by a server for

determining a frequency and voltage of one or more processors of the server, according to still an exemplifying embodiment.

[00012] Figure 1 c is a flowchart of a method performed by a server for

determining a frequency and voltage of one or more processors of the server, according to yet an exemplifying embodiment.

[00013] Figure 2a is a block diagram of an exemplifying server supporting DVFS.

[00014] Figure 2b is a block diagram of a prediction engine according to an example.

[00015] Figure 2c illustrates an example of a neural network structure for prediction. [00016] Figure 2d is a signalling diagram illustrating an example of the method performed by the server.

[00017] Figure 3 is a block diagram of a server for determining a frequency and voltage of one or more processors of the server, according to an exemplifying embodiment.

[00018] Figure 4 is a block diagram of a server for determining a frequency and voltage of one or more processors of the server, according to another exemplifying embodiment.

[00019] Figure 5 is a block diagram of an arrangement in a server for determining a frequency and voltage of one or more processors of the server, according to an exemplifying embodiment.

Detailed description

[00020] Briefly described, a server and a method performed thereby for determining a frequency and voltage of one or more processors of the server, wherein the server supports DVFS and the server runs one or more virtual machines are provided. The server makes use of incoming traffic in the form of packets that are buffered in the server to predict amount of compute resource utilisation associated with the buffered packets. Based on amount of compute resource utilisation associated with the buffered packets, the server determines voltage and/or frequency of one or more processors of the server before releasing the buffered packets to the processor(s) for processing service(s) associated with the buffered packets.

[00021 ] Embodiments of such a method performed by a server for determining a frequency and voltage of one or more processors of the server will now be described with reference to figures 1a-1c. The server supports Dynamic Voltage and Frequency Scaling, DVFS, and the server runs one or more virtual machines.

[00022] Figure 1a illustrates the method 100 comprising receiving 1 10 incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; buffering 120 the received one or more packets; and predicting 130 amount of compute resource utilisation associated with the buffered one or more packets. The method also comprises determining 140 voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and releasing 150 the stored one or more packets to the one or more processor based on the predicted amount of compute resource utilisation and the determined voltage and frequency.

[00023] The DVFS enables the server to manage power consumption of the server, e.g. with regard to the one or more processors of the server. Depending on the circumstances, e.g. the load of the one or more processors of the server or the amount of incoming traffic to the server, the server may increase or decrease the voltage. The server may alternatively or additionally increase or decrease the frequency in order to reduce power consumption and/or meet the requirement(s) of performance of the server. The server may be part of a datacentre or be the only server of a datacentre.

[00024] The server receives 1 10 incoming traffic by means of one or more packets addressed to one or more virtual machines. Looking briefly at figure 2a, the server runs one or more virtual machines. The virtual machine(s) may execute different services or applications associated with the packets of the incoming traffic.

[00025] The server may buffer 120 the received one or more packets, e.g. by putting the received one or more packets in one or more buffers of the server. Traffic to the server may come irregularly, meaning that there may not be a constant flow of packets coming to the server. Rather, the packets may be received at irregular time intervals. Merely as an illustrative example, during a first millisecond the server may receive one packet, during the following second millisecond the server may receive four packets, during the third millisecond the server does not receive any packets and during the fourth millisecond the server may receive twelve packets. Depending on restraints on allowable delay associated with services related to the received packets, it may not be necessary for the server to process the packets at every millisecond, perhaps it is enough to process the received packets once every seven or tenth millisecond in order to fulfil Quality of Service, QoS, Service Level Agreements, SLAs etc. Thus, the server may buffer the received one or more packets.

[00026] Using the received one or more packets, the server may predict 130 amount of compute resource utilisation associated with the buffered one or more packets. Different packets may be related to, or associated with, different services. Different services may require more or less processing, e.g. number of compute cycles. Assume the received one or more packets relate to three different services, wherein the first service requires two compute cycles per received packet, the second service requires four two compute cycles per received packet, and the third service requires seven compute cycles per received packet. Then the server may look at the number of packets in the buffer related to the first service, the number of packets in the buffer related to the second service, and the number of packets in the buffer related to the third service; and based on the number of compute cycles per service the server may predict the amount of compute resource utilisation associated with the buffered one or more packets.

[00027] The server may then determine 140 voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation. Depending on the amount of compute resource utilisation that is required according to the prediction, the one or more processors need to consume a minimum amount of energy. Generally, the higher the voltage and/or the higher the frequency, the more capacity the processor(s) have and the more power it/they consume. Consequently, if too high a voltage or too high a frequency is applied, the one or more processors will process the services related to the packets but at a unnecessarily high power consumption. Analogously, if too low a voltage or too low a frequency is applied, the one or more processors will not be able to process the services related to the packets (at least not in time), wherein the service(s) may risk being delayed or unsatisfactorily performed.

[00028] Based on the predicted amount of compute resource utilisation and the determined voltage and frequency, the server may then release 150 the stored one or more packets to the one or more processors. The server may also apply the determined voltage and frequency to the one or more processors. In this manner, the server may ensure that just enough power is consumed by the one or more processors, wherein the services related to the packets of the incoming traffic are executed in a manner fulfilling e.g. QoS, SLA etc.

[00029] The method performed by the server has several advantages. One possible advantage is that it may reduce the power consumption of a processor in a server (or datacentre). This may reduce operation expenditures and increase for environmental friendliness of the server. Another possible advantage is that constraints related to service time may be maintained, thus providing transparent trade-offs to the operator in this respect. Still a further possible advantage is that control and overview of the resources used in the network for a given service or application is enabled. Yet a possible advantage is that correlations may be found and knowledge may be created or obtained to make recommendations that enable the optimisation of resources allocated to cloud computing.

[00030] The method may further comprise, as illustrated in figure 1 b, configuring 1 15 an energy consumption model for an application instance and information regarding delay constraints and/or QoS requirements associated with the application executed by the application instance, wherein the amount of compute resource utilisation associated with incoming packet to that application instance may be predicted by the configured energy consumption model.

[00031 ] By configuring the energy consumption model for an application instance and information regarding delay constraints and/or QoS requirements associated with the application executed by the application instance, a correlation between power consumption and load of the one or more processors may be obtained. The power consumption model may then provide the server with information about the expected power consumption by the one or more processors for processing the buffered packets.

[00032] The energy consumption model module may determine whether the expected power consumption associated with the CPU load could be optimised with regard to DVFS. [00033] The releasing 150 of the buffered one or more packets to the one or more processor may also be based on delay constraints and/or QoS requirements associated with the one or more packets.

[00034] Different packets may be associated with different services having individual and different delay constraints and/or QoS requirements. For example, delay constraints and/or QoS requirements may make it impossible for the server to buffer the received packets for too long. In case a service related to packets in the buffer(s) of the server is time critical, the server may be forced to release the buffered one or more packets after a certain time.

[00035] Consequently, the server cannot keep the one or more packets in the buffer for too long, waiting for the buffer to fill up in order to minimise power consumption.

[00036] The releasing 150 of the buffered one or more packets to the one or more processor may also be based on number of packets in a buffer and/or buffer status.

[00037] The server may comprise one or more buffers in which packets may be buffered before being released to the one or more processors. In case a buffer is getting relatively full, e.g. being used to a threshold level of its maximum capacity, the server may need to release the packets therein to the one or more processors.

[00038] The one or more packets may be addressed to one or more application instances running on the virtual machine(s).

[00039] As described above, the server may be running and/or executing one or more virtual machines. Virtual machines may run, or execute, one or more application instances. An example of an application instance is a Virtual Network Function, VNF.

[00040] Reverting to the simplified and illustrative example above, different VNFs may be associated with different number of compute cycles per received packet. [00041 ] The method may further comprise, as illustrated in figure 1c, collecting 1 16 statistics about incoming traffic, and determining 1 17 a relation between incoming traffic and compute resource utilisation for different traffic arrival rates, wherein the determining 140 of voltage and frequency for one or more processors is also based on the collected statistics and the determined relation between incoming traffic and compute resource utilisation for different traffic arrival rates.

[00042] Statistics about incoming traffic may comprise received number of incoming packets per time unit, received number of packets of different types per time unit. Generally, amount of traffic varies over time having peeks of very high load or intensity and dips of very low load or intensity. Traffic is generally random but certain peeks and dips often occur around the same time each day and/or each night.

[00043] Such information may be used by the server for determining voltage and frequency for one or more processors, especially together with the determined relation between incoming traffic and compute resource utilisation for different traffic arrival rates.

[00044] Figure 2a is a schematic illustration of a server of a datacentre. Figure 2a illustrates the server comprising hardware and software. As a part of the software is a virtualisation management framework 230, e.g. a Hypervisor, such as a Kernel-based Virtual machine (KVM), Xen or container management. The virtualisation management framework 230 comprises a prediction engine 231 . The prediction engine 231 takes as input network traffic statistics addressed to e.g. a VNF (application instance or service) 21 1 a, 21 1 b, 21 1 c that is being executed in a virtual machine 210a, 210b, 210c being managed by the virtualisation management framework 230, and estimates the compute resource (CPU) utilisation associated with processing the traffic. Another component of the virtualisation management framework 230 is a buffer control entity 235, which receives input from the prediction engine 231 with respect to how many packets should be aggregated and delivered to the VNF 21 1 a, 21 1 b, 21 1 c in one batch for processing. The buffer control 235 could, in addition, be configured to take into account constraints related to the service time for the particular VNF to which the packets are being addressed, and ensure that packets are not delayed too much (or it could be configured simply with a generic policy of aggregating packets for at most 100 ms, for example). Furthermore, an existing DVFS

Governor component is configured to receive input from the prediction engine 231 to manage, aligned with the prediction engine forecasts, frequency and voltage scales and access to physical Network Interface Control(s) 260, NIC(s), of the server 200.

[00045] When a new application/service/VNF 21 1 a, 21 1 b, 21 1 c is to be deployed on the server, information regarding service constraints (service time and or QoS) as well as an initial energy consumption estimation model may be configured in the prediction engine 231 . Furthermore, a NIC driver (not shown) in the virtuahsation manager 230 may be configured to collect statistics and inform the prediction engine 231 regarding the arrival of traffic for the particular VNF instance 21 1 a, 21 1 b, 21 1 c. Thus, the prediction engine 231 may query specific network statistics in a privileged domain containing one or more virtual switches 220a, 220b in order to match with configured constraints. More specifically, in a Xen-based server, the prediction engine 231 may query network statistics for a dedicated privileged domain (DomO) node (e.g. in the virtuahsation manager 230) containing one or more para-virtualised NIC (not shown) for each unprivileged domain (DomU) hosted in the hypervisor. In a KVM-based environment, network statistics from a bridged/routed connection may be obtained by virtual platform managers such as Libvirt and Nagios-virt. Furthermore, as hypervisors need to bridge traffic between virtual machines and the outside world (intra and inter communication), a number of open source virtuahsation frameworks (e.g. Xen, KVM or Docker) may include support for virtual switching to enable richer networking capabilities rather than standard Linux bridge capabilities (such as security policies and QoS requirements for each virtual machine within the hypervisor domain).

[00046] As illustrated in figure 2a, a virtual switch 220a, 220b may be

equivalent to a Layer 2 (L2) switch, which connects virtual NICs (front-end network adapter) of the various virtual machines to a virtual NIC in a privileged domain (either a special virtual machine or within the virtual platform domain) containing a backend driver to forward packets to a physical NIC. As each virtual NIC receive a unique Ethernet MAC address, a simple L2 matching allows identifying workload from VNFs 221 a, 21 1 b, 21 1 c deployed in virtual machines 210a, 210b, 210c through interface counters. Further, virtual switches such as Open vSwitch may be a component for implementing Software Defined

Networking, SDN-, based solutions which allows capturing inter-domain (external to the server domain) and intra-domain (between virtual machines in the server domain) traffic statistics.

[00047] Upon receiving traffic statistics from a virtualisation management framework 230, the prediction engine 231 may employ a model which has been pre-configured to determine the relation between network traffic and CPU utilisation for a certain traffic arrival rate. The model in the prediction engine 231 could be made self-adjusting, meaning that it would use a feedback loop based on data from the DVFS governor 238 for modifying its parameters in order to match performance constraints of a particular version of both the underlying hardware and the software of the VNF 221 a, 21 1 b, 21 1 c that is executed.

[00048] Figure 2b depicts the main components of the prediction engine 231 according to one exemplifying illustration. In this example, it is composed of a traffic prediction model, a VNF/Application/memory prediction model, and a resource power consumption model. The traffic prediction model receives network traffic statistics as input from historical database. The main focus of the traffic prediction model is to predict how much CPU will be consumed by a service (VNF), from traffic statistics obtained within a given time window. In this disclosure, the model may be built through Artificial Neural Networks, ANNs. ANNs are used in several domains and has high prediction ability with low overhead fit in a dynamic real time setting.

[00049] The neural network prediction model contains neurons connected to each other and to the input and output layer. The neurons may be trained by a supervised learning algorithm called Backpropagation. The initial prediction engine configuration for the model may be the result of an offline learning process (for example, a VNF vendor may train several instances of these models in a laboratory for different types of hardware on which a VNF may run). This algorithm may use a network structure called Multi-Layer Perceptron, MLP, which has three or more neuron layers. The first layer is the input layer and the last is the output layer, containing only a single neuron. The intermediate layers are called hidden layers (in figure 2c one such layer is shown, but multiple layers may be configured), containing neurons representing free parameters or weights. When the network receives the input data, it examines the output response to the input pattern. During the offline training phase, an error value may then be calculated by comparing the known and desired output. The backpropagation algorithm adjusts the weights of the hidden layers to gradually minimise error values. We consider that the offline training phase is successfully completed and weight values may be used to pre-configure the model parameters in the prediction engine 231 during normal operations.

[00050] The solution disclosed herein may use a MLP with tree layers, where the input layer is x(i), the hidden layer is w(i) and output layer is y(i). Figure 2c presents an example of the neural network structure for prediction. To make the neural prediction effective, the neural network should be trained on a

representative data set.

[00051 ] Once the model is created, it is used for predicting the CPU load, from new information of the network traffic statistics arising from the system at a given time window. This output is then used as the input of the resource power consumption model. From this information, this component is responsible for estimate the power consumption of such resource. Models of power consumption versus CPU load are widely known and available in literature. The resource power consumption model module determines whether the expected power consumption associated with the CPU load could be optimised by the DVFS governor and if so, signals the Buffer Control, BC, module to release the packets towards the VNF. If the power consumption cannot be optimised, it signals the BC to store or keep storing the packets in the buffer (figure 2c, steps 1 -5). [00052] The BC 235, illustrated in figure 2a, is a queue management system able to perform queuing actions on packets for both intra-domain and inter- domain communication for the various virtual NICs defined for VNFs. It decides when to release the buffer based on buffer occupancy, power consumption estimates received from the prediction engine 231 , and potentially policies from the operator (for example, delay constraints for certain VNFs or packet

categories). Then, the BC 235 forwards a request to the DVFS governor 238 with the predicted resource usage for the content of the buffer, allowing the DVFS governor 238 to configure the processor frequency and voltage in order to optimise the power consumption. Alternately, the DVFS governor 238 may query the BC 235 at any time for the current workload stored and predicted power usage. An example of a DVFS algorithm that finds the slowest speed that guarantee a task feasibility is included below. The algorithm receives as input a set of tasks and a worst case pre-emption cost:

1 : function dvfs_speed (tasks: set of tasks, pcost worst case preemption cost):

2: s^* - compute_critical_speed()

3: S' <- {s ε S I s > s*} //speeds in ascending order

4: for each s ε S' do:

5: Bmin <-□

6: for each i ε fas/ s[1 , n] do:

7: Qimax <- min (Ci(s), Bmin + 1 )

8: Bi <- compute_task_tolerance(l, s, pcost)

9: Bmin <- min (Bi, Bmin)

10: if Bmin < 0 then:

1 1 : break

12: end if

13: end for

14: if Bmin >= 0 then:

15: return [s, Bmin]

16: end if

17: end for

18: return No speed found

19: end function

20:

21 : pcost <r 0

22: pred_tasks <- workload_prediction(Buffer_Control) // return a prediction of tasks

23: sched_tasks <- dvfs_speed(pred_tasks, pcost) //return the speed of each given scheduled task

24: if sched _tasks > up_threshold then: 25 increase_processor_frequency()

26 else if sched _tasks < down_threshold then:

27 decrease_processor_frequency()

28 end if

[00053] Embodiments herein also relate to a server for determining a frequency and voltage of one or more processors of the server that supports DVFS. The server runs one or more virtual machines. The server has the same technical features, objects and advantages as the method performed by the server described above. The server will therefore be described only in brief in order to avoid unnecessary repetition. The server will be described with reference to figures 3 and 4.

[00054] Figure 3 illustrates the server 300, 400 being configured for receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; buffering the received one or more packets; and predicting amount of compute resource utilisation associated with the buffered one or more packets. The server 300, 400 is further configured for determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and releasing the stored one or more packets to the one or more processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

[00055] The server 300, 400 may be realised or implemented in different ways. A first exemplifying implementation or realisation is illustrated in figure 3. Figure 3 illustrates the server 300 comprising a processor 321 and memory 322, the memory comprising instructions, e.g. by means of a computer program 323, which when executed by the processor 321 causes the server 300 to receive incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; to buffer the received one or more packets; and to predict amount of compute resource utilisation associated with the buffered one or more packets. The memory further comprises instructions, which when executed by the processor 321 causes the server 300 to determine voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and to release the stored one or more packets to the one or more processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

[00056] Figure 3 also illustrates the server 300 comprising a memory 310. It shall be pointed out that figure 3 is merely an exemplifying illustration and memory 310 may be optional, be a part of the memory 322 or be a further memory of the server 300. The memory may for example comprise information relating to the server 300, to statistics of operation of the server 300, just to give a couple of illustrating examples. Figure 3 further illustrates the server 300 comprising processing means 320, which comprises the memory 322 and the processor 321 . Still further, figure 3 illustrates the server 300 comprising a communication unit 330. The communication unit 330 may comprise an interface through which the server 300 e.g. receives incoming traffic. Figure 3 also illustrates the server 300 comprising further functionality 340. The further functionality 340 may comprise hardware or software necessary for the server 300 to perform different tasks that are not disclosed herein.

[00057] An alternative exemplifying implementation of the server 300, 400 is illustrated in figure 4. Figure 4 illustrates the server 400 comprising a receiving unit 403 for receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; a buffering unit 404 for buffering the received one or more packets; and a predicting unit 405 for predicting amount of compute resource utilisation associated with the buffered one or more packets. The server 300, 400 is illustrated also comprising a determining unit 406 for determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and a releasing unit 407 for releasing the stored one or more packets to the one or more processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

[00058] In figure 4, the server 400 is also illustrated comprising a

communication unit 401. Through this unit, the server 400 is adapted to e.g.

receive incoming traffic. The server 400 is further illustrated comprising a memory 402 for storing data. Further, the server 400 may comprise a control or processing unit (not shown) which in turn is connected to the different units 403-407. It shall be pointed out that this is merely an illustrative example and the server 400 may comprise more, less or other units or modules which execute the functions of the server 400 in the same manner as the units illustrated in figure 4.

[00059] It should be noted that figure 4 merely illustrates various functional units in the server 400 in a logical sense. The functions in practice may be implemented using any suitable software and hardware means/circuits etc. Thus, the embodiments are generally not limited to the shown structures of the server 400 and the functional units. Hence, the previously described exemplary

embodiments may be realised in many ways. For example, one embodiment includes a computer-readable medium having instructions stored thereon that are executable by the control or processing unit for executing the method actions or steps in the server 400. The instructions executable by the computing system and stored on the computer-readable medium perform the method actions or steps of the server 400 as set forth in the claims.

[00060] The server receiver has the same possible advantages as the method performed by the server. One possible advantage is that it may reduce the power consumption of a processor in a server (or datacentre). This may reduce operation expenditures and increase for environmental friendliness of the server. Another possible advantage is that constraints related to service time may be maintained, thus providing transparent trade-offs to the operator in this respect. Still a further possible advantage is that control and overview of the resources used in the network for a given service or application is enabled. Yet a possible advantage is that correlations may be found and knowledge may be created or obtained to make recommendations that enable the optimisation of resources allocated to cloud computing.

[00061 ] According to an embodiment, the server 300, 400 is further configured for configuring an energy consumption model for an application instance and information regarding delay constraints and/or QoS requirements associated with the application executed by the application instance, wherein the amount of compute resource utilisation associated with incoming packet to that application instance may be predicted by the configured energy consumption model.

[00062] According to yet an embodiment, the releasing of the buffered one or more packets to the one or more processor is also based on delay constraints and/or Quality of Service requirements associated with the one or more packets.

[00063] According to still an embodiment, the releasing of the buffered one or more packets to the one or more processor is also based on number of packets in a buffer and/or buffer status.

[00064] According to another embodiment, the one or more packets is/are addressed to one or more application instances running on the virtual machine(s).

[00065] According to a further embodiment, the server 300, 400 is further configured for collecting statistics about incoming traffic, and determining a relation between incoming traffic and compute resource utilisation for different traffic arrival rates, wherein the server (300, 400) is configured for determining of voltage and frequency for one or more processors also based on the collected statistics and the determined relation between incoming traffic and compute resource utilisation for different traffic arrival rates.

[00066] Figure 5 schematically shows an embodiment of an arrangement 500 in a server 400. Comprised in the arrangement 500 in the server 400 are here a processing unit 506, e.g. with a Digital Signal Processor, DSP. The processing unit 506 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 500 of the server 400 may also comprise an input unit 502 for receiving signals or traffic from other entities, and an output unit 504 for providing signal(s) or traffic to other entities. The input unit and the output unit may be arranged as an integrated entity or as illustrated in the example of figure 4, as one or more interfaces 401 .

[00067] Furthermore, the arrangement 500 in the server 400 comprises at least one computer program product 508 in the form of a non-volatile memory, e.g. an Electrically Erasable Programmable Read-Only Memory, EEPROM, a flash memory and a hard drive. The computer program product 508 comprises a computer program 510, which comprises code means, which when executed in the processing unit 506 in the arrangement 500 in the server 400 causes the server to perform the actions e.g. of the procedure described earlier in conjunction with figures 1a-1c.

[00068] The computer program 510 may be configured as a computer program code structured in computer program modules 510a-510e. Hence, in an

exemplifying embodiment, the code means in the computer program of the arrangement 500 in the server 400 comprises a receiving unit, or module, for receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines; a buffering unit, or module, for buffering the received one or more packets; and a predicting unit, or module, for predicting amount of compute resource utilisation associated with the buffered one or more packets. The arrangement 500 in the server 400 further comprises a determining unit, or module, for determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation; and a releasing unit, or module, for releasing the stored one or more packets to the one or more processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

[00069] The computer program modules could essentially perform the actions of the flow illustrated in figures 1a-1c, to emulate the server 400. In other words, when the different computer program modules are executed in the processing unit 506, they may correspond to the units 403-407 of figure 4.

[00070] Although the code means in the embodiments disclosed above in conjunction with figure 4, is implemented as computer program modules which when executed in the respective processing unit causes the server to perform the actions described above in the conjunction with figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits. [00071 ] The processor may be a single Central Processing Unit, CPU, but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits, ASICs. The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-Access Memory RAM, Read-Only Memory, ROM, or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the server.

[00072] It is to be understood that the choice of interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions.

[00073] It should also be noted that the units described in this disclosure are to be regarded as logical entities and not with necessity as separate physical entities.

[00074] While the embodiments have been described in terms of several embodiments, it is contemplated that alternatives, modifications, permutations and equivalents thereof will become apparent upon reading of the specifications and study of the drawings. It is therefore intended that the following appended claims include such alternatives, modifications, permutations and equivalents as fall within the scope of the embodiments and defined by the pending claims.

Claims

1 . A method (100) performed by a server for determining a frequency and voltage of one or more processors of the server that supports Dynamic Voltage and Frequency Scaling, DVFS, the server running one or more virtual machines, the method comprising:

- receiving (1 10) incoming traffic to the server by means of one or more

packets addressed to one or more virtual machines,

- buffering (120) the received one or more packets,

- predicting (130) the amount of compute resource utilisation associated with the buffered one or more packets,

- determining (140) voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation, and

- releasing (150) the stored one or more packets to the one or more

processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

2. The method (100) according to claim 1 , further comprising configuring (1 15) an energy consumption model for an application instance and information regarding delay constraints and/or Quality of Service requirements associated with the application executed by the application instance, wherein the amount of compute resource utilisation associated with incoming packet to that application instance may be predicted by the configured energy consumption model.

3. The method (100) according to claim 1 or 2, wherein the releasing (150) of the buffered one or more packets to the one or more processor is also based on delay constraints and/or Quality of Service requirements associated with the one or more packets.

4. The method (100) according to any of claims 1 -3, wherein the releasing (150) of the buffered one or more packets to the one or more processor is also based on number of packets in a buffer and/or buffer status.

5. The method (100) according to any of claims 1 -4, wherein the one or more packets is/are addressed to one or more application instances running on the virtual machine(s).

6. The method (100) according to any of claims 1 -5, further comprising collecting (1 16) statistics about incoming traffic, and determining (1 17) a relation between incoming traffic and compute resource utilisation for different traffic arrival rates, wherein the determining (140) of voltage and frequency for one or more processors is also based on the collected statistics and the determined relation between incoming traffic and compute resource utilisation for different traffic arrival rates.

7. A server (300, 400) for determining a frequency and voltage of one or more processors of the server that supports Dynamic Voltage and Frequency Scaling, DVFS, the server running one or more virtual machines, the server (300, 400) being configured for:

- receiving incoming traffic to the server by means of one or more packets addressed to one or more virtual machines,

- buffering the received one or more packets,

- predicting amount of compute resource utilisation associated with the

buffered one or more packets,

- determining voltage and frequency for one or more processors based on the predicted amount of compute resource utilisation, and

- releasing the stored one or more packets to the one or more processor based the predicted amount of compute resource utilisation and the determined voltage and frequency.

8. The server (300, 400) according to claim 7, further being configured for configuring an energy consumption model for an application instance and information regarding delay constraints and/or Quality of Service requirements associated with the application executed by the application instance, wherein the amount of compute resource utilisation associated with incoming packet to that application instance may be predicted by the configured energy consumption model.

9. The server (300, 400) according to claim 7or 8, wherein the releasing of the buffered one or more packets to the one or more processor is also based on delay constraints and/or Quality of Service requirements associated with the one or more packets.

10. The server (300, 400) according to any of claims 7-9, wherein the releasing of the buffered one or more packets to the one or more processor is also based on number of packets in a buffer and/or buffer status.

1 1 . The server (300, 400) according to any of claims 7-10, wherein the one or more packets is/are addressed to one or more application instances running on the virtual machine(s).

12. The server (300, 400) according to any of claims 7-1 1 , further being configured for collecting statistics about incoming traffic, and determining a relation between incoming traffic and compute resource utilisation for different traffic arrival rates, wherein the server (300, 400) is configured for determining of voltage and frequency for one or more processors also based on the collected statistics and the determined relation between incoming traffic and compute resource utilisation for different traffic arrival rates.

13. A Computer program (510), comprising computer readable code means, which when run in a processing unit (506) comprised in an arrangement (500) in a server (400) according to claims 7-12 causes the server (500) to perform the corresponding method according to any of claims 1 -6.

14. A Computer program product (508) comprising the computer program (510) according to claim 13.