Patent Publication Number: US-10334029-B2

Title: Forming neighborhood groups from disperse cloud providers

Description:
BACKGROUND OF THE INVENTION 
     Field of the Invention 
     The disclosed technology relates to delivery of computing as a service. In particular, example embodiments relate to partitioning and operating a portion of computing resources not traditionally used in a cloud fashion as resources available as a service. 
     Description of the Related Art 
     Traditional data centers tend to run a single operating system instance and a single business application on one physical server. This “one server, one appliance” model leads to extremely poor resource utilization. Wasted resources include CPU, RAM, Storage, and Network Bandwidth. 
     “Cloud computing” refers to a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that may be rapidly provisioned and released with minimal management effort or service provider interaction. The cloud computing model is characterized by on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Cloud computing service models include software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). Cloud computing deployment models include public clouds, private clouds, community clouds, and hybrid combinations thereof. The cloud model can allow end users to reduce capital expenditures and burdensome operating costs associated with maintaining substantial information technology expertise and operating staff in house. 
     Typical cloud computing and storage solutions provide users and enterprises with various capabilities to store and process their data in third-party data centers that may be located far from the user—ranging in distance from across a city to across the world. Cloud computing relies on sharing of resources to achieve coherence and economy of scale, similar to a utility (like the electricity grid) over an electricity network. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other sample aspects of the present technology will be described in the detailed description and the appended claims that follow, and in the accompanying drawings, wherein: 
         FIG. 1  illustrates a block diagram of an example network topology for forming neighborhood groups from disperse cloud providers; 
         FIG. 2  illustrates provider data for example disperse cloud providers; 
         FIG. 3  illustrates an example characteristic scoring tree for generating vectors to represent disperse cloud providers; 
         FIG. 4  illustrates an example three-axis space for grouping disperse cloud providers; 
         FIG. 5  illustrates an example methodology for tracking usage of virtual machines; and 
         FIG. 6  illustrates a block diagram of an example computer system. 
     
    
    
     BRIEF INTRODUCTION 
     The following presents a simplified summary of one or more embodiments in order to provide a basic understanding of present technology. This summary is not an extensive overview of all contemplated embodiments of the present technology, and is intended to neither identify key or critical elements of all examples nor delineate the scope of any or all aspects of the present technology. Its sole purpose is to present some concepts of one or more examples in a simplified form as a prelude to the more detailed description that is presented later. In accordance with one or more aspects of the examples described herein, systems and methods are provided for tracking usage of distributed software for virtual machines. 
     The subject disclosure provides systems and methods for forming neighborhood groups from disperse cloud providers. A cloud manager receives provider data relating to a plurality of disperse cloud providers for a plurality of data subcategories classified under N-number main categories. The cloud manager generates a respective vector to represent each of the plurality of disperse cloud providers based on the provider data to yield vectors. The cloud manager generates an N-number axis space comprising the vectors. The cloud manager groups the plurality of disperse cloud providers in the N-number axis space into at least one cloud provider group, based on the vectors and a clustering algorithm. 
     DETAILED DESCRIPTION 
     The subject disclosure provides techniques for forming neighborhood groups from disperse cloud providers, in accordance with the subject technology. Various aspects of the present technology are described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It can be evident, however, that the present technology can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these aspects. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. 
     The power of traditional end user environments is exploding. Some estimate that the compute power of the equivalent of a personal computer, such as found in the typical home environment, in 2049 may be equal to all computing power created through 2012. Further, the ability of home environments to offer services and products (south-to-north, south-to-west, and south-to-east traffic) may expand. This is similar to how some people offer home-generated electrical power to public utilities. This trend opens the door for “utility computing,” where the consumer can share the excess of his home cloud or IT infrastructure with peers, Internet Service Providers (ISPs), application providers, or third parties. This capability effectively may transform the consumer of goods and services into a market resident who owns a home infrastructure and allocates part of it to create a cloud and offer services and products to peers, ISPs, application providers, or third parties. In some embodiments, it allows customers to become entrepreneurs and de-facto application providers and/or crowd-sourced public cloud providers. 
     Similar to cloud computing, fog computing can provide data, compute, storage, and application services to end-users. Fog computing or fog networking, is an architecture that uses one or more collaborative multitude of end-user clients or near-user edge devices to carry out a substantial amount of storage (rather than stored primarily in cloud data centers), communication (rather than routed over the internet backbone), control, configuration, measurement and management (rather than controlled primarily by network gateways such as those in the LTE core network). 
     Computing resources of each of a plurality of first parties, such as residential subscribers to an Internet Service Provider (ISP), can be logically partitioned into a first party end user partition and a first party crowd sourced cloud partition. Home, businesses, schools, and universities, could all participate in a crowd sourced cloud as providers of services, capacity, or both. These entities can provide one or more devices or appliances (i.e., “computing resources”) that can provide compute, network, or storage capacity in a context of space, power, and cooling. 
     In example architectures for the technology, while each server, system, and device shown in the architecture is represented by one instance of the server, system, or device, multiple instances of each can be used. Further, while certain aspects of operation of the technology are presented in examples related to the figures to facilitate enablement of the disclosed concepts, additional features of the technology, also facilitating enablement of the concepts, are disclosed elsewhere herein. 
     The subject disclosure provides a cloud manager that receives provider data for multiple disperse cloud providers. The cloud manager analyzes the provider data and groups the disperse cloud providers into one or more cloud provider groups. By placing certain cloud providers together into particular cloud provider groups, the cloud providers can pool computing resources more effectively to better serve cloud end users. 
     Given that many of the disperse cloud providers are expected to be from home environments, the end-user apps can be based upon a micro-services application architecture. In the micro-services application architecture, applications can be moved to another home-cloud infrastructure without impacting consumer experience. Micro-service architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism. 
       FIG. 1  illustrates a block diagram of an example network topology  100  for forming neighborhood groups from disperse cloud providers  150 . The example network topology  100  shows an example arrangement of various network elements of a network  101 . It should be noted that the example network topology  100  is merely an example arrangement for demonstration and does not describe all possible types of network configurations for use with the claimed invention. 
     The network  101  can include a wide area network (WAN) such as the Internet, or a local area network (LAN). The network  101  can include an intranet, a storage area network (SAN), a personal area network (PAN), a metropolitan area network (MAN), a wireless local area network (WLAN), a virtual private network (VPN), a cellular or other mobile communication network, a BLUETOOTH® wireless technology connection, a near field communication (NFC) connection, any combination thereof, and any other appropriate architecture or system that facilitates the communication of signals, data, and/or messages. Throughout the discussion of example embodiments, it should be understood that the terms “data” and “information” are used interchangeably herein to refer to text, images, audio, video, or any other form of information that can exist in a computer-based environment. 
     A cloud manager  130 , diverse cloud providers  150 , and cloud end users  160  are connected to the network  101 . For example, if the network  101  is the Internet, the diverse cloud providers  150  and the cloud end users  160  can connect to the network  101  through one or more Internet Service Providers (ISPs)  110 A-C. For example, ISPs  110 A,  110 B,  110 C are shown in  FIG. 1  for illustration. An ISP is an organization that provides services for accessing and using the Internet. Internet Service Providers may be organized in various forms, such as commercial, community-owned, non-profit, or otherwise privately owned. Internet services typically provided by ISPs include Internet access, Internet transit, domain name registration, web hosting, Usenet service, and colocation. Each ISP typically serves large groups of Internet users in a geographic area. 
     The network computing devices, such as the cloud manager  130 , the diverse cloud providers  150 , the cloud end users  160 , and any other computing machines associated with the technology presented herein, may be any type of computing machine such as, but not limited to, those discussed in more detail with respect to  FIG. 6 . Furthermore, any functions, applications, or modules associated with any of these computing machines, such as those described herein or any others (for example scripts, web content, software, firmware, or hardware) associated with the technology presented herein may by any of the modules discussed in more detail with respect to  FIG. 6 . The computing machines discussed herein may communicate with one another as well as other computer machines or communication systems over one or more networks, such as network  101 . The network  101  may include any type of data or communications network, including any of the network technology discussed with respect to  FIG. 6 . 
     The diverse cloud providers  150  can be located in various geographic locations. For example, one or more diverse cloud providers  150  may be located in each single zip code  140 . For example, zip code  140 A, zip code  140 B, and zip code  140 C are shown in  FIG. 1  for illustration. It is possible, but not necessary for all diverse cloud providers  150  located in a single zip code  140 B to also be serviced by a single ISP B 110 B. In contrast, diverse cloud providers  150  in zip code  140 A are served by ISP  110 B and  110 C. 
     The cloud manager  130  can include any computing or processing device, such as for example, one or more computer servers. The cloud manager  130  can be a single device, multiple devices in one location, or multiple devices in multiple locations. In some implementations, the cloud manager  130  can be combined with or include the network computing devices for one or more of the diverse cloud providers  150  or the cloud end users  160 . 
     Each of the diverse cloud providers  150  can include one or more computing devices of various configurations.  FIG. 2  describes in more detail example cloud provider configurations. 
       FIG. 2  illustrates provider data  200  for example disperse cloud providers  210 - 260 . It should be noted that the example disperse cloud providers  210 - 260  are provided merely for demonstration and does not describe all possible types of computing device configurations for use with the claimed invention. The diverse cloud providers  210 - 260  may be any type of computing machine such as, but not limited to, those discussed in more detail with respect to  FIG. 6 . The diverse cloud providers  210 - 260  are each described by provider data in various categories, such as but not limited to, those described below. 
     Each disperse cloud provider  210 - 260  is located at particular a geographic address and offers a certain amount of computing resources to a cloud provider group. One or more physical computer servers can be located at the geographic address and include the computing resources offered. 
     The computing resources can be measured by any of a variety of performance metrics for system sources and computational resources. System resources include physical or virtual entities of limited availability (e.g., memory, processing capacity, and network speed). Computational resources include resources used for solving a computational problem (e.g., computation speed, memory space). 
     Computing resources, from one or more computer servers, can include, but are not limited to, CPUs, processing power—often measured in flops/second, memory such as random access memory (RAM), storage such as hard disk drives and/or solid state drives, and network connectivity—often measured in megabits/second (mbps) of data transmission speed and latency. The FLoating-point Operations Per Second (flops) is a measure of computer performance, useful in fields of scientific calculations that make heavy use of floating-point calculations. 
     Provider data for each disperse cloud provider  210 - 260  can include internet protocol (IP) addresses of the computer servers, internet service provider (ISP) identification and router IP address. An Internet Protocol address (IP address) is a numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication. An IP address serves two principal functions: host or network interface identification and location addressing. Its role has been characterized as follows: “A name indicates what we seek. An address indicates where it is. A route indicates how to get there.” 
     IP addresses were initially defined as a 32-bit number and this system, known as Internet Protocol Version 4 (IPv4), is still in use today. However, because of the growth of the Internet and the predicted depletion of available addresses, a new version of IP (IPv6), using 128 bits for the address, was developed in 1995. 
     Provider data for each disperse cloud provider  210 - 260  can include the type of service level agreements (SLAs). The SLA is an official commitment that prevails between a service provider and the customer. Particular aspects of the service, such as quality, availability, responsibilities, are agreed between the service provider and the service user. The most common component of SLA is that the services should be provided to the customer as agreed upon in the contract. As an example, Internet service providers and telecommunications companies will commonly include SLAs within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms. For example, the SLA will typically have a technical definition in terms of mean time between failures (MTBF), mean time to repair or mean time to recovery (MTTR) (i.e. identifying which party is responsible for reporting faults or paying fees), responsibility for various data rates, throughput, jitter, or similar measurable details. 
     Provider data for each disperse cloud provider  210 - 260  can include a resource allocation type. For example, the allocation type can be a split ratio 1:1 type or a best effort type of allocation. If the allocation type is the best effort type, then the provider data may include an addon resource limit for additional CPU, RAM, and/or storage use. 
     The provider data for each disperse cloud provider  210 - 260  can also include the types of software that each server is running, such as the operating system (OS) type and/or version, cloud software, etc. 
     The disperse cloud provider  210  represents Resident 1 located at 123 ABC Lane, San Jose, USA. The disperse cloud provider  210  offers two servers including a total of two central processing units (CPUs) and one teraflop/second (T-flops/s) of processing power. The disperse cloud provider  210  includes four gigabytes (gb) of RAM, 20 gb of storage, and two mbps of Internet connection speed. The disperse cloud provider  210  connects to the Internet with the ISP provider AT&amp;T and has the IP address 10.1.1.1 for a first server and 10.1.1.2 for a second server. 
     The disperse cloud provider  210  has a SLA that provides for 50% availability of the computing resources on the two servers for cloud use. The SLA also provides a dedicated resources allocation policy per server. The disperse cloud provider  210  allocates resources into a split ratio 1:1 type with no addon resource flexibility. In addition, the two servers both run the Linux OS. 
     While not shown in  FIG. 2 , the provider data for the disperse cloud providers  210 - 260  can include data relating to: cost model, allocation model, percentage of SLAs met, user ratings, resources used, machine learning data for user usage patterns, and/or cloud size, etc. For example, the provider data for cost model can include a price per unit of storage or processing power that a disperse cloud provider will charge. The provider data for the allocation model can include whether addon resource for the disperse cloud provider is flexible or fixed. The provider data for the percentage of SLAs met can include data for the amount of compliance with SLAs. The provider data for the user ratings can include a user satisfaction score from one to ten. The provider data for the resources uses can include data for the total amount computing resources provided by the disperse cloud provider. The provider data for the cloud side can include whether the disperse cloud provider is a small, medium, or large provider (e.g, based on number of servers offered or amount of computing resources offered). 
     As shown in  FIG. 2 , the provider data for disperse cloud providers  220 - 260  provide similar information describing Residents 2-6. 
       FIG. 3  illustrates an example characteristic scoring tree  300  for generating vectors to represent disperse cloud providers. The provider data for a single disperse cloud provider, as described in the examples shown in  FIG. 2 , can be categorized under a number of main categories. In addition, the provider data can be further categorized under a number subcategories under the main categories. Each subcategory can be unique to one of the main categories or can exist under multiple main categories. 
     The example characteristic scoring tree  300  includes three main categories: feasibility (Z)  310 , offering similarity (X)  320 , and provider credibility (Y)  330 . Each of the main categories includes four subcategories. For example, the feasibility (Z) main category  310  includes the subcategories: ISP provider  312 , cloud provider location  314 , network type  316 , and computing type  318 . The offering similarity main category  320  can include the subcategories: SLAs  322 , cost model  324 , allocation model  326 , and addon resource  328 . The provider credibility main category  330  can include the subcategories: percentage of SLAs met  332 , user ratings  334 , resources used  336 , and cloud size  338 . Even though the example characteristic scoring tree  300  shown in  FIG. 3  includes three main categories, more or less than three main categories can be applied to the subject disclosure. 
     It should be noted that the characteristic scoring tree  300  is merely an example categorical arrangement for demonstration and does not describe all possible types of arrangements for use with the claimed invention. 
     In some implementations, the provider data for each subcategory is a numerical value. Each of the subcategories in a main category can be summed into a single numerical value to represent the X, Y, or Z. For example, numerical values for the ISP provider  312 , the cloud provider location  314 , the network type  316 , and the computing type  318  can be summed into a value for the feasibility main category (Z)  310 . Numerical values for the SLAs  322 , the cost model  324 , the allocation model  326 , and the addon resource  328  can be summed into a value for the offering similarity main category (X)  320 . Likewise, numerical values for the percentage of SLAs met  332 , the user ratings  334 , the resources used  336 , and the cloud size  338  can be combined into a value for the provider credibility main category (Z)  330 . Of course, the values in the trees are representative. Other values can also be used as well as any mixture of values or parameters. 
     The combination of the values of X, Y, and Z for the three main categories can be used to generate a three element vector such as (x, y, z) for the disperse cloud provider. In this manner, the cloud manager generates a three element vector for each of the respective disperse cloud providers. In some implementations, the number of elements in the generated vectors can match the number of main categories provided by the provider data. The vector can also include one element, two elements or more than three elements. 
       FIG. 4  illustrates an example three-axis space  400  for grouping disperse cloud providers  401 - 406 . The space  400  has three-axis to match the number of elements in each vector for the disperse cloud providers  401 - 406 . In other implementations, more (e.g., four or more) or less (e.g, one or two) axis spaces can be used. For example, if there are N-number of main categories and a corresponding N-number of elements in each vector, a N-number axis space is also used. Different coordinate systems besides a Cartesian coordinate system could be used as well. 
     The three-axis space  400  includes a respective vector corresponding to each disperse cloud provider  401 - 406 . The cloud manager groups the disperse cloud providers together into different cloud groups, based on their vector values in the three-axis space. 
       FIG. 4  illustrates the three-axis space plane  1   400 A to show only a first X-Y plane of the three-axis space  400  at a first Z value (e.g., Z=111 here). Similarly the three-axis space plane  2   400 B illustrates only a second X-Y plane of the three-axis space  400  at a second Z value (e.g., Z=222 here). In some implementations, the cloud manager only groups together vectors on the same axis plane (e.g., the Z axis shown in  FIG. 4 ). In some other implementations, the cloud manager does not require vectors in the same cloud group to be on any single plane. Even though  FIG. 4  shows a three-axis space, one-axis, two-axis, or four or more axis can also be applied to the subject disclosure. In other implementations, more (e.g., four or more) or less (e.g, one or two) axis spaces can be used. Different coordinate systems besides a Cartesian coordinate system could be used as well. 
     In some implementations, the cloud manager uses a clustering algorithm to group the vectors for the disperse cloud providers into different cloud groups. For example, the cloud manager can use a KMeans clustering algorithm. However, KMeans is only one of many possible clustering algorithms for use by the cloud manager. 
     KMeans clustering is a method of vector quantization, originally from signal processing, that is popular for cluster analysis in data mining. KMeans clustering aims to partition n observations into k clusters in which each observation belongs to the cluster with the nearest mean, serving as a prototype of the cluster. This results in a partitioning of the data space into Voronoi cells. 
     A Voronoi diagram is a partitioning of a plane into regions based on distance to points in a specific subset of the plane. That set of points (called seeds, sites, or generators) is specified beforehand, and for each seed there is a corresponding region consisting of all points closer to that seed than to any other. These regions are called Voronoi cells. 
     The most common KMeans algorithm uses an iterative refinement technique. Given an initial set of observations, the KMeans algorithm proceeds by alternating between two steps, an assignment step and an update step. In the assignment step, assign each observation to the cluster whose mean yields the least within-cluster sum of squares (WCSS). Since the sum of squares is the squared Euclidean distance, this is intuitively the “nearest” mean. In the update step, calculate the new means to be the centroids of the observations in the new clusters. The algorithm has converged when the assignments no longer change. Since both steps optimize the WCSS objective, and there only exists a finite number of such partitioning, the algorithm must converge to a local optimum. The algorithm is often presented as assigning objects to the nearest cluster by distance. The standard algorithm aims at minimizing the WCSS objective, and thus assigns by “least sum of squares”, which is exactly equivalent to assigning by the smallest Euclidean distance. 
     In some implementations, the clustering algorithm is a suggested and supervised KMeans (SS-KMeans) clustering algorithm, and where each grouping of one of the plurality of disperse cloud providers reinforces the SS-KMeans clustering algorithm. 
       FIG. 4  illustrates an example KMeans clustering algorithm applied to a six vectors  401 - 406  corresponding to six respective disperse cloud providers. The vectors  401 - 406  are each possessed sequentially. The vectors can be processed in any order based on any number of factors. 
     The cloud manger plots R 1   401  with vector ( 30 ,  25 ,  111 ) on plane  1   400 A. Since R 1   401  is first, R 1   401  is placed into cloud group (i.e., “cluster”)  421 . The cloud manager plots R 2  with vector ( 20 ,  20 ,  111 ) on plane  1   400 A. Since the cloud group  421  is the only available cluster, R 2  will get the cloud group  421  as a “suggested” grouping to choose from. The cloud manager places R 2   402  with R 1   401  into the cloud group  421 . When R 2   402  joins R 1   401  in the cloud group  421 , this is called supervised clustering. When a disperse cloud provider joins an existing cloud group, the training set of the supervised clustering is reinforced. The cloud manager generates a KMeans value for R 1   401  and R 2   402  in cloud group  421 . 
     The cloud manager plots R 3   403  ( 40 ,  40 ,  111 ) on plane  1   400 A. Since plane  1   400 A has one cluster  421  including R 1   401  and R 2   402 , R 3   403  will get a “suggested” grouping based on a mean proximity of cluster  421  to R 3 . In this case, R 3   403  selects to be in separate cluster  422 . Now there are two clusters or cloud groups (i.e., k=2). One KMean is based on cluster  421  including R 1   401  and R 2   402  and the other Kmean is based just based on cluster  422  including R 3   403 . 
     The cloud manager plots R 4  ( 20 ,  30 ,  111 )  404  on plane  1   400 A. Now plane  1  has two clusters  421 ,  422 . R 4   404  selects to be part of cluster  421 . The total number of clusters remains at two. Cluster  421  receives a new KMean. Now cluster  421  includes R 1   401 , R 2   402 , and R 4   404  and cluster  422  includes R 3   403 . 
     In the example shown in  FIG. 4 , a separate KMeans is applied to plane  2   400 B. The cloud manager plots R 5  ( 30 ,  30 ,  222 )  405  on plane  2   400 B, since vector R 5   405  has a Z value of  222 . Vector R 5   405  is placed into cluster  424 . The cloud manager plots R 6  ( 30 ,  40 ,  222 )  406  to plan  2   400 B. R 6   406  is placed into cluster  425 . 
       FIG. 5  illustrates an example methodology  500  for tracking usage of virtual machines. At step  510 , the cloud manager receives provider data relating to a plurality of disperse cloud providers for a plurality of data subcategories classified under N-number main categories. 
     In some implementations, the cloud manager determines a respective numerical value to represent each of the plurality of data subcategories for each of the plurality of disperse cloud providers. The N-number main categories can include at least one of a feasibility decision score, offering similarity score, or provider credibility score. The plurality of data subcategories can include at least one of internet service provider, provider location, network type, computing type, service level agreement (SLA), cost model, allocation model, resource flexibility, percentage SLA met, user ratings, resource used, or cloud size. 
     At step  520 , the cloud manager generates a respective vector to represent each of the plurality of disperse cloud providers based on the provider data to yield vectors. Each respective element of the vector can be based on the provider data for one of the N-number main categories. 
     At step  530 , the cloud manager generates an N-number axis space including the vectors. 
     At step  540 , the cloud manager groups the plurality of disperse cloud providers in the N-number axis space into at least one cloud provider group, based on the vectors and a clustering algorithm. 
     In some implementations, grouping the plurality of disperse cloud providers includes grouping each respective vector in the N-number axis space into one of the at least one cloud provider group, based on the clustering algorithm. The clustering algorithm can be a KMeans clustering algorithm that groups the data points in the N-number axis space into k-number clusters. 
     In some implementations, the clustering algorithm is a suggested and supervised KMeans (SS-KMeans) clustering algorithm, and where each grouping of one of the plurality of disperse cloud providers reinforces the SS-KMeans clustering algorithm. The clustering algorithm can be an agglomerative hierarchical clustering algorithm or a divisive hierarchical clustering algorithm. 
     In some implementations, the cloud manager monitors for a change in the provider data for a disperse cloud provider. When there is a change in the provider data for a disperse cloud provider, the cloud manager generates an updated vector for the disperse cloud provider, and regroups the disperse cloud provider. 
       FIG. 6  illustrates a block diagram of an example processing system  600 . The processing system  600  can include a processor  640 , a network interface  650 , a management controller  680 , a memory  620 , a storage  630 , a Basic Input/Output System (BIOS)  610 , and a northbridge  660 , and a southbridge  670 . 
     The processing system  600  can be, for example, a server (e.g., one of many rack servers in a data center) or a personal computer. The processor (e.g., central processing unit (CPU))  640  can be a chip on a motherboard that can retrieve and execute programming instructions stored in the memory  620 . The processor  640  can be a single CPU with a single processing core, a single CPU with multiple processing cores, or multiple CPUs. One or more buses (not shown) can transmit instructions and application data between various computer components such as the processor  640 , memory  620 , storage  630 , and networking interface  650 . 
     The memory  620  can include any physical device used to temporarily or permanently store data or programs, such as various forms of random-access memory (RAM). The storage  630  can include any physical device for non-volatile data storage such as a HDD or a flash drive. The storage  630  can have a greater capacity than the memory  620  and can be more economical per unit of storage, but can also have slower transfer rates. 
     The BIOS  610  can include a Basic Input/Output System or its successors or equivalents, such as an Extensible Firmware Interface (EFI) or Unified Extensible Firmware Interface (UEFI). The BIOS  610  can include a BIOS chip located on a motherboard of the processing system  600  storing a BIOS software program. The BIOS  610  can store firmware executed when the computer system is first powered on along with a set of configurations specified for the BIOS  610 . The BIOS firmware and BIOS configurations can be stored in a non-volatile memory (e.g., NVRAM)  612  or a ROM such as flash memory. Flash memory is a non-volatile computer storage medium that can be electronically erased and reprogrammed. 
     The BIOS  610  can be loaded and executed as a sequence program each time the processing system  600  is started. The BIOS  610  can recognize, initialize, and test hardware present in a given computing system based on the set of configurations. The BIOS  610  can perform self-test, such as a Power-on-Self-Test (POST), on the processing system  600 . This self-test can test functionality of various hardware components such as hard disk drives, optical reading devices, cooling devices, memory modules, expansion cards and the like. The BIOS can address and allocate an area in the memory  620  in to store an operating system. The BIOS  610  can then give control of the computer system to the OS. 
     The BIOS  610  of the processing system  600  can include a BIOS configuration that defines how the BIOS  610  controls various hardware components in the processing system  600 . The BIOS configuration can determine the order in which the various hardware components in the processing system  600  are started. The BIOS  610  can provide an interface (e.g., BIOS setup utility) that allows a variety of different parameters to be set, which can be different from parameters in a BIOS default configuration. For example, a user (e.g., an administrator) can use the BIOS  610  to specify clock and bus speeds, specify what peripherals are attached to the computer system, specify monitoring of health (e.g., fan speeds and CPU temperature limits), and specify a variety of other parameters that affect overall performance and power usage of the computer system. 
     The management controller  680  can be a specialized microcontroller embedded on the motherboard of the computer system. For example, the management controller  680  can be a BMC or a RMC. The management controller  680  can manage the interface between system management software and platform hardware. Different types of sensors built into the computer system can report to the management controller  680  on parameters such as temperature, cooling fan speeds, power status, operating system status, etc. The management controller  680  can monitor the sensors and have the ability to send alerts to an administrator via the network interface  650  if any of the parameters do not stay within preset limits, indicating a potential failure of the system. The administrator can also remotely communicate with the management controller  680  to take some corrective action such as resetting or power cycling the system to restore functionality. 
     The northbridge  660  can be a chip on the motherboard that can be directly connected to the processor  640  or can be integrated into the processor  640 . In some instances, the northbridge  660  and the southbridge  670  can be combined into a single die. The northbridge  660  and the southbridge  670 , manage communications between the processor  640  and other parts of the motherboard. The northbridge  660  can manage tasks that require higher performance than the southbridge  670 . The northbridge  660  can manage communications between the processor  640 , the memory  620 , and video controllers (not shown). In some instances, the northbridge  660  can include a video controller. 
     The southbridge  670  can be a chip on the motherboard connected to the northbridge  660 , but unlike the northbridge  660 , is not directly connected to the processor  640 . The southbridge  670  can manage input/output functions (e.g., audio functions, BIOS, Universal Serial Bus (USB), Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect (PCI) bus, PCI eXtended (PCI-X) bus, PCI Express bus, Industry Standard Architecture (ISA) bus, Serial Peripheral Interface (SPI) bus, Enhanced Serial Peripheral Interface (eSPI) bus, System Management Bus (SMBus), etc.) of the processing system  600 . The southbridge  670  can be connected to or can include within the southbridge  670  the management controller  670 , Direct Memory Access (DMAs) controllers, Programmable Interrupt Controllers (PICs), and a real-time clock. 
     The input device  602  can be at least one of a game controller, a joystick, a mouse, a keyboard, a touchscreen, a trackpad, or other similar control device. The input device  602  allows a user to provide input data to the processing system  600 . 
     The display device  604  can be at least one of a monitor, a light-emitting display (LED) screen, a liquid crystal display (LCD) screen, a head mounted display (HMD), a virtual reality (VR) display, a augmented reality (AR) display, or other such output device. The display device  604  allows the processing system  600  to output visual information to a user. 
     The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein can be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. 
     The operations of a method or algorithm described in connection with the disclosure herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal. 
     In one or more exemplary designs, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. Non-transitory computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blue ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable media. 
     The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.