Energy estimation system and method for openBMC-based firmware stack

Abstract

The invention relates to an energy estimation system and method for an openBMC-based firmware stack. Embodiments of the present disclosure provide an energy estimation system and method for an openBMC-based firmware stack that empirically determines a power load offset value that can be applied to a BMC executing the openBMC-based firmware stack to enable an IHS to run more efficiently. According to one embodiment, an information handling system (IHS) includes a baseboard management controller (BMC) including firmware to apply a power load offset value to adjust a speed of one or more fans configured on a target IHS when an openBMC-based firmware stack is executed on the BMC, and to apply a power load offset value to adjust a speed of one or more fans configured on the target IHS when a standard firmware stack is executed on the BMC. The power load offset value is applied to adjust the speed of the fan without applying the power load offset value.

Description

Background Technology

[0001] As the value and use of information increase, individuals and businesses seek additional ways to process and store it. One option available to users is an Information Processing System (IHS). An IHS generally processes, compiles, stores, and / or communicates information or data for business, personal, or other purposes, thereby allowing users to utilize the value of information. Because the technologies and information required for processing vary among different users or applications, an IHS can also vary regarding what information is processed, how it is processed, how much information is processed, stored, or communicated, and how quickly and efficiently it is processed, stored, or communicated. Variations in an IHS allow it to be general-purpose or configured for a specific user or use case, such as financial transaction processing, airline booking, corporate data storage, or global communications. Furthermore, an IHS can include various hardware and software components that can be configured to process, store, and transmit information and can include one or more computer systems, data storage systems, and networked systems.

[0002] Modern IHS administration is typically provided via a Baseboard Management Controller (BMC), also known as a Remote Access Controller (RAC). A BMC generally consists of a dedicated microcontroller embedded within the IHS and provides an interface between the system management software and the platform hardware. Different types of sensors built into the IHS report parameters (such as temperature, cooling fan speed, power status, operating system (O / S) status, etc.) to the BMC. The BMC monitors the sensors, and if any parameter deviates from preset limits, it can send an alert to the administrator via the network, indicating a potential system failure. The administrator can also communicate remotely with the BMC to take corrective actions, such as resetting the system or powering it back on to restore suspended O / S functionality. This capability can often reduce the overall cost of owning an IHS, especially when implemented in large clusters such as server farms. Summary of the Invention

[0003] Embodiments of this disclosure provide an energy estimation system and method for an openBMC-based firmware stack, which empirically determines a power load offset value that can be applied to a BMC executing the openBMC-based firmware stack to make the IHS operate more efficiently. According to one embodiment, an information processing system (IHS) includes a baseboard management controller (BMC) that includes firmware to apply a power load offset value to adjust the speed of one or more fans configured on a target IHS when an openBMC-based firmware stack is executed on the BMC, and to apply the power load offset value to adjust the fan speed without applying the power load offset value when a standard firmware stack is executed on the BMC.

[0004] According to another embodiment, an energy estimation method for an openBMC-based firmware stack includes the steps of applying a power load offset value to adjust the speed of one or more fans configured on an information processing system (IHS) associated with the BMC when the openBMC-based firmware stack is executed on a baseboard management controller (BMC), and applying the power load offset value to adjust the speed of the fans without applying the power load offset value when a standard firmware stack is executed on the BMC.

[0005] According to yet another embodiment, a baseboard management controller (BMC) includes the steps of applying a power load offset value to adjust the speed of one or more fans configured on an information processing system (IHS) associated with the BMC when an openBMC-based firmware stack is executed on the baseboard management controller (BMC), and applying the power load offset value to adjust the speed of the fans without applying the power load offset value when a standard firmware stack is executed on the BMC. Attached Figure Description

[0006] The present invention(s) are illustrated by way of example and are not limited by the accompanying drawings. The elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale.

[0007] Figure 1 This is a block diagram illustrating an example of components of an information processing system (IHS) according to an embodiment of the present disclosure.

[0008] Figure 2A The illustration shows a spreadsheet window according to one embodiment of the present disclosure, the spreadsheet being used to determine offset values ​​for an IHS managed by an openBMC-based firmware stack.

[0009] Figure 2BAn example table is illustrated according to one embodiment of the present disclosure, showing how to obtain power load offset values.

[0010] Figure 3 An example of an openBMC-based firmware stack energy estimation method according to an embodiment of the present disclosure is illustrated, which can be executed to adjust the speed of one or more fans in an IHS. Detailed Implementation

[0011] This disclosure is described with reference to the accompanying drawings. The drawings are not to scale and are provided only to illustrate the disclosure. Various aspects of the disclosure are described below with reference to exemplary applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide an understanding of the disclosure. This disclosure is not limited by the order of the illustrated actions or events, as some actions may occur in a different order and / or simultaneously with other actions or events. Furthermore, not all illustrated actions or events are required to implement the methods according to this disclosure.

[0012] Some IHSs can be configured with a BMC (Band Control Center) to monitor and, in some cases, manage the computer hardware components of their respective IHS. The BMC is typically programmed using a firmware stack that configures it to perform out-of-band (e.g., external to the computer's operating system or BIOS) hardware management tasks. The BMC firmware may support industry-standard specifications such as the Intelligent Platform Management Interface (IPMI) for Computer System Administration and the Server Hardware System Management Architecture (SMASH).

[0013] BMC firmware is typically proprietary and usually developed by the vendor, and is shipped to the end user along with the BMC. However, the industry trend has shifted towards custom BMC firmware stacks (e.g., operating systems) that allow end users greater control over how the BMC operates. OpenBMC is an example standard under which firmware stacks based on OpenBMC can be built. Broadly speaking, openBMC is a collaborative open-source Linux distribution for BMCs designed to work across heterogeneous systems, including enterprise, high-performance computing (HPC), telecommunications, and cloud-scale data centers.

[0014] While openBMC-based firmware stacks (such as firmware stacks implemented according to the openBMC standard) offer enhanced manageability, transparency, and customizability, their implementation is not without drawbacks. For example, standard BMC firmware stacks are typically implemented by the vendor of the IHS where the BMC is deployed, and therefore, the quality and reliability of the BMC's functionality can be controlled to a relatively high degree. An example of such a standard BMC firmware stack is the iDRAC firmware stack provided by Dell Technologies. On the other hand, openBMC-based firmware stacks, often developed in uncontrolled environments, typically suffer from relatively high levels of software failures (e.g., bugs). A particular type of firmware stack is the Open Server Manager (OSM), built on the openBMC standard and provided by Dell Technologies.

[0015] Due to certain software limitations of openBMC-based stacks, these stacks lack access to certain thermal sensors required to provide proper cooling for IHS. For example, most openBMC-based firmware stacks do not have access to the thermal sensors on the card configured in the PCIe card slot. Most standard firmware stacks do not have this problem with thermal sensor utilization and can therefore support different operating modes (e.g., system idle mode, maximum load, etc.) with a properly calibrated fan table.

[0016] One workaround for platform thermal design is to scale fan speeds proportionally during IHS idle mode when using an openBMC-based firmware stack. Therefore, the openBMC-based firmware stack generates more idle power compared to a standard firmware stack. However, this issue can be quite dramatic. For example, it is estimated that the difference in energy used by a single IHS server over the IHS's lifetime could cost as much as $15,000. As will be described in detail below, embodiments of this disclosure provide an energy estimation system and method for an openBMC-based firmware stack that empirically determines a power load offset value that can be applied to a BMC implementing the openBMC-based firmware stack to make the IHS operate more efficiently.

[0017] For the purposes of this disclosure, an IHS may include any means or aggregate of means operable to calculate, account for, determine, classify, process, transmit, receive, retrieve, initiate, switch, store, display, communicate, exhibit, detect, record, reproduce, manage, or utilize any form of information, intelligence, or data for transactional, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., a desktop or laptop computer), a tablet computer, a mobile device (e.g., a personal digital assistant (PDA) or a smartphone), a server (e.g., a blade server or rack server), a network storage device, or any other suitable device, and may vary in size, shape, performance, function, and price.

[0018] An IHS may include random access memory (RAM), one or more processing resources (such as a central processing unit (CPU) or hardware or software control logic), ROM, and / or other types of non-volatile memory. Additional components of the IHS may include one or more disk drives, one or more network ports for communicating with external devices, and various input and output (I / O) devices, such as a keyboard, mouse, touchscreen, and / or video display. The IHS may also include one or more buses operable to transmit communication between various hardware components.

[0019] Figure 1 This is a block diagram illustrating examples of components of an Information Processing System (IHS) according to some embodiments. Specifically, IHS 100 includes one or more processors 102 coupled to system memory 104 via system interconnect 106. System interconnect 106 may include any suitable system bus. System memory 104 may include multiple software modules and / or firmware modules, including firmware (F / W) 108, a basic input / output system (BIOS) 110, an operating system (O / S) 112, and / or multiple applications 114. The multiple software modules and / or firmware modules stored in system memory 104 may be loaded onto the multiple processors 102 and executed during operation of IHS 100.

[0020] The IHS100 includes one or more input / output (I / O) controllers 118 that manage the operation of one or more connected input / output devices 120, such as keyboards, mice, touchscreens, microphones, monitors or display devices, cameras, microphones, (multiple) audio speakers (not shown), optical readers, Universal Serial Bus (USB), card readers, PCMCIA slots, and / or High Definition Multimedia Interface (HDMI), which may be included in or coupled to the IHS100.

[0021] IHS100 includes a Network Interface Device (NID) 122. NID 122 enables IHS100 to communicate and / or interface with other devices, services, and components located outside of IHS100. These devices, services, and components (such as System Management Console 126) can interface with IHS100 via an external network (such as network 124), which may include a local area network (LAN), wide area network (WAN), personal area network (PAN), the Internet, etc.

[0022] System memory 104 may include a UEFI interface 140 and / or an SMBIOS interface 142 for accessing and updating the BIOS 110. Generally, the UEFI interface 140 provides a software interface between the operating system and the BIOS 110. In many cases, the UEFI interface 140 can support remote diagnostics and repair of the computer, even without an operating system installed. The SMBIOS interface 142 can be used to read management information generated by the BIOS 110 of the IHS 100. This feature eliminates the need for the operating system to directly probe the hardware to discover what devices are present in the computer.

[0023] The IHS100 also includes one or more power supply units (PSUs) 130. The PSUs 130 are connected via I... 2 The C-bus is coupled to the BMC132. The BMC132 enables remote operation control of other components within the IHS100 and the PSU130. The PSU130 powers the hardware devices of the IHS100, such as processors 102, system memory 104, non-volatile memory 134, NID 122, I / O controller 118, PSU 130, etc. To help maintain the temperature within specifications, an active cooling system, such as one or more fans 136, can be used.

[0024] IHS100 also includes one or more sensors 146. For example, sensor 146 may include a thermal sensor that thermally communicates with certain hardware devices (such as processor 102 or PSU 130) that generate a relatively large amount of heat. Sensor 146 may also include a voltage sensor that communicates signals to BMC 132 associated with, for example, electronic voltage or electronic current at an input line of PSU 130, and / or electronic voltage or electronic current at an output line of PSU 130.

[0025] The BMC 132 can be configured to provide out-of-band management facilities for the IHS100. Management operations can be performed by the BMC 132 even when the IHS100 is powered off or in standby mode. The BMC 132 may include a processor, memory, and an out-of-band network interface that is separate from and physically isolated from the IHS100's in-band network interface and / or other embedded resources.

[0026] In some embodiments, BMC 132 may include or be a portion of a remote access controller (e.g., a DELL Remote Access Controller (DRAC) or an integrated DRAC (iDRAC)). In other embodiments, BMC 132 may include or be a component of a chassis management controller (CMC).

[0027] F / W 108 includes a fan table 148 for storing fan speed data for certain hardware devices, such as processors 102, system memory 104, non-volatile memory 134, NID 122, I / O controller 118, etc. Generally, fan table 148 may be populated with values ​​indicating the fan speeds used for some, most, or all fans in IHS 100 when certain conditions are met. According to embodiments of this disclosure, the values ​​in fan table 148 may be configured to adjust the fan speed values ​​based on an offset value representing a measured difference between the power consumed by IHS 100 managed by an openBMC-based firmware stack and the power consumed by IHS 100 managed by a standard firmware stack. While fan table 148 is shown stored in F / W 108 of IHS 100, it should be understood that fan table 148 may be stored in any suitable storage location, such as in secure non-volatile memory (NVM) of IHS 100. The following section will describe in detail the additional details associated with fan table 148.

[0028] Figure 2AThe illustration shows a table window 200 of a table according to an embodiment of the present disclosure, used to determine offset values ​​for an IHS managed by an openBMC-based firmware stack. The table window 200 includes three columns 202a to 202c, respectively illustrating various characteristics of a first IHS 100, a second IHS 100, and a third IHS 100 managed by the openBMC-based firmware stack. Specifically, column 202a is associated with an IHS 100 having a low-end ES configuration type, column 202b is associated with an IHS 100 having a typical ES configuration type, and column 202c is associated with an IHS 100 having a high-end ES configuration type. Characteristics include those that can directly affect the amount of power used by each IHS 100. As shown, characteristics may include the type of processor(s) used, the amount of volatile memory configured in each IHS 100, the amount of non-volatile memory configured in each IHS 100, the type of PSU used, and the number of external I / O ports configured on the IHS 100.

[0029] The electronic meter window 200 includes three rows 206a to 206c, which indicate the measured power used by the IHS100 during idle mode 206a, medium load mode 206b, and maximum load mode 206c. The electronic meter window 200 also includes three columns 204a to 204c, which respectively show various characteristics of the first, second, and third IHS100s managed by the standard firmware stack. The electronic meter window 200 also includes three rows 206a to 206c, which indicate the measured power used by the IHS100 during idle mode 206a, medium load mode 206b, and maximum load mode 206c.

[0030] For each of the different types of IHS100 (e.g., low-end, mid-end, high-end), a power usage offset can be obtained, indicating the difference in power used by the IHS100 when managed by an openBMC-based firmware stack compared to when managed by a standard firmware stack. For example, rows 208a to 208c show the offset values ​​for each low-end, mid-end, and high-end IHS100 at idle, mid-load, and maximum load states, respectively. Specifically, cell C15 indicates the power usage offset for the low-end IHS100 at idle, while cell E17 indicates the power usage offset for the high-end IHS100 at maximum load. It is worth noting that the server used in the spreadsheet window 200 is a single-processor server, and measurements should be performed in a similar manner for dual-processor servers.

[0031] In one embodiment, the average power usage offset can be calculated for each power load level (e.g., idle state, mid-load state, maximum load state) measured by the system. For example, cell G15 indicates the average power load offset for each of the low-end, mid-end, and high-end IHS100 at the idle level; cell G16 indicates the average power load offset for each of the low-end, mid-end, and high-end IHS100 at the mid-load state; and cell G17 indicates the average power load offset for each of the low-end, mid-end, and high-end IHS100 at the maximum load state.

[0032] In one embodiment, the power load offset value can be calculated according to the Standard Performance Evaluation Organization (SPEC) standard. According to the SPEC standard, the Lot9 active efficiency requirement specifies that a dual-processor server (IHS) should have an efficiency ratio of at least 9.5. Thus, according to Equation 1, the efficiency of a dual-processor server operating with an openBMC-based firmware stack 152b can be related to its power usage:

[0033] Equation 1:

[0034] Among them, OSMEFF base2p The efficiency of the server is managed by the firmware stack based on OpenBMC, and Pwrserver2 P This is the amount of power actually used by the server. Additionally, the idle power consumed by the server can be set according to Equation 2:

[0035] Equation 2:

[0036] OSMIdle base2P It is 21.315911, and IdlePower 2P It is 21.32.

[0037] According to the SPEC standard, the Lot9 active efficiency requirement specifies that a single-processor server (IHS) should have an efficiency ratio of at least 9. Thus, according to Equation 3, the efficiency of a server with a processor running alongside an openBMC-based firmware stack 152b can be related to its power consumption:

[0038] Equation 3:

[0039] OSMEFF 1Pdelta The performance of the server, Pwrserver, is managed by the openBMC-based firmware stack 152b.1P It is the amount of power used by the server, and OSMEFF base2P It is -188.6. Additionally, the difference in idle power used by a dual-processor server versus a single-processor server can be determined according to Equation 4:

[0040] Equation 4: OSMIdle 1Pdelta =IdlePower 1P -IdlePower 2P

[0041] IdlePower 1P This is the idle power used by a single-processor server, and IdlePower 2P This is the idle power used by dual-processor servers.

[0042] Figure 2B An example table is illustrated, showing how the power load offset value can be obtained from Equations 1-4 according to one embodiment of this disclosure. As shown, the difference in idle power is relatively small, and therefore the power load offset value is not used. However, for a dual-processor server, the power load offset value is -188.6 watts under normal use and 21.32 watts under idle, and for a single-processor server, the power load offset value is -18.33 watts under normal use and 0.41 watts under idle. It should be understood that the power load offset value is calculated for servers managed by an OSM-based openBMC firmware stack, and different power load offset values ​​can be obtained when using other firmware stacks that conform to the openBMC standard.

[0043] In one embodiment, the average power usage offset can be stored in a fan table 148, such that when using the standard firmware stack 152a, the values ​​in the fan table 148 are used to set the speed of fan(s) 136 without using the power load offset value; when using the openBMC-based firmware stack 152b, the values ​​in the fan table 148 are used to set the speed of fan(s) 136 by using the power load offset value. Therefore, in this way, the power load offset value can be used to accurately set the speed of fan(s) 136 without requiring access to all thermal sensors configured in the IHS 100, such as when the openBMC-based firmware stack 152b cannot access the thermal sensors via the PCIe bus.

[0044] In some embodiments, only one power load offset value or a very small power load offset value may be used. For example, the average power load level at idle is shown as 22 watts, while the average power load levels at median load and maximum load are shown as 9.1 watts and 4.3 watts, respectively. Therefore, only the average power load value at idle is used to provide fan speed adjustment.

[0045] Figure 3 An example of an openBMC-based firmware stack energy estimation method 300 according to one embodiment of the present disclosure is illustrated, which can be executed to adjust the speed of one or more fans in an IHS 100. In one embodiment, method 300 can be executed wholly or at least partially by either a standard firmware stack 152a or an openBMC-based firmware stack 152b that is loaded on and executed by BMC 132.

[0046] Initially at step 302, when the standard firmware stack 152a is used to manage the IHS100, the power load levels of the IHS100 are empirically measured. In one embodiment, multiple power load levels can be empirically measured at different power states (e.g., idle state, median load state, maximum load state, etc.). In another embodiment, power load levels can be empirically obtained for different IHS configurations (e.g., low-end, typical, high-end, etc.). At step 304, when the openBMC-based firmware stack 152a is used to manage the IHS100, the power load levels(s) of the IHS100 are empirically measured.

[0047] At step 306, method 300 then uses the measured power load value to obtain a power load offset value. In one embodiment, method 300 may obtain multiple power load offset values ​​for different power load levels that the IHS 100 may provide. In another embodiment, method 300 may obtain multiple power load offset values ​​for different IHS configurations (e.g., low-end, typical, high-end, etc.) and average the multiple power load values ​​to obtain an average power load value. In yet another embodiment, method 300 may use the Standard Performance Evaluation Organization (SPEC) standard minimum efficiency ratio to obtain the power load offset value.

[0048] At step 308, method 300 stores multiple power load offset values ​​in the target IHS 100. In one embodiment, the multiple power load offset values ​​may be stored in a fan table 148. In another embodiment, the fan table 148 may be stored in a secure memory location within the target IHS 100. The target IHS 100 is then started at step 310.

[0049] Method 300 then determines whether to use a standard firmware stack or an openBMC-based firmware stack to manage the operation of the target IHS 100. For example, either the standard firmware stack 152a or the openBMC-based firmware stack 152b loaded on BMC 132 may include information (e.g., hardcoded) to know whether it is the standard firmware stack 152a or the openBMC-based firmware stack 152b. If BMC 132 is loaded with the standard firmware stack 152a, the process continues at step 314, where the power load offset value is not used to set the speed of any of the fans(s)136 in the target IHS 100. However, if BMC 132 is loaded with the openBMC-based firmware stack 152b, the process continues at step 316, where the power load offset value is used to set or otherwise adjust the speed of the fans(s)136 in the target IHS 100. During the operation of the target IHS100 or until the target IHS100 is shut down, either step 314 or step 316 is performed continuously. When the target IHS100 is restarted (e.g., rebooted), steps 310 to 316 can be performed again to appropriately adjust the speed of(multiple) fans to enhance the efficiency of the target IHS100.

[0050] although Figure 3 An example of a method for adjusting the speed of fans(s)136 in a target IHS100 when an openBMC-based firmware stack 152b is loaded onto a BMC 132 is described. However, the characteristics of the disclosed process may be embodied in other specific forms without departing from the spirit and scope of this disclosure. For example, method 300 may perform additional, fewer, or different operations than those described in this example. As another example, certain steps of the above process may be performed by the BMC 132 and / or other components of the target IHS 100, such as by a controller chip configured on the BMC 132 or by a BIOS 110 executed on the target IHS 100.

[0051] It should be understood that the various operations described herein can be implemented in software or software modules executed by logic circuits or processing circuits, hardware, or a combination thereof. The order in which each operation of a given method is performed can be changed, and various operations can be added, reordered, combined, omitted, modified, etc. It is intended that the invention described herein include all such modifications and variations; therefore, the foregoing description should be considered illustrative rather than restrictive.

[0052] Although the present invention(s) has been described herein with reference to specific embodiments, various modifications and alterations may be made without departing from the scope of the present invention(s), as set forth in the following claims. Therefore, the specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present invention(s). Any benefits, advantages, or solutions to problems described herein with reference to specific embodiments are not intended to be construed as key, essential, or fundamental features or elements of any or all claims.

[0053] Unless otherwise stated, terms such as “first” and “second” are used to distinguish the elements described by such terms. Therefore, the term is not necessarily intended to indicate time priority or other priority of such elements. The term “coupled” or “operably coupled” is defined as a connection, although it is not necessarily a direct connection and is not necessarily a mechanical connection. Unless otherwise stated, the terms “a” and “an” are defined as one or more. The terms “comprising” (and any form of inclusion, such as “including” and “containing”), “having” (and any form of having, such as “having” and “having”), “including” (and any form of inclusion, such as “includes” and “containing”), and “containing” (and any form of inclusion, such as “accommodating” and “including”) are open-ended linking verbs. As a result, a system, device, or apparatus that “composes,” “has,” “includes,” or “comprises” one or more elements possesses, but is not limited to, possessing only those one or more elements. Similarly, a method or process that “comprising,” “has,” “includes,” or “accommodates” one or more operations possesses, but is not limited to, possessing only those one or more operations.

Claims

1. A target information processing system (IHS), comprising: A substrate management controller (BMC) manages the operation of the IHS. The BMC includes one or more processors and one or more memory units, the memory units including instructions that, when executed by the processor, cause the BMC to: When the openBMC-based firmware stack is executed on the BMC, a power load offset value is applied to adjust the speed of one or more fans configured on the target IHS. as well as When the standard firmware stack is executed on the BMC, the power load offset value is applied to adjust the speed of the fan instead of the power load offset value.

2. The IHS of claim 1, wherein the instruction further causes the BMC to: apply one of the plurality of power load offset values ​​based on the current power load of the target IHS.

3. The IHS of claim 1, wherein the power load offset value is obtained using the standard performance evaluation organization SPEC standard minimum efficiency ratio.

4. The IHS of claim 1, wherein the power load offset value is obtained by averaging the power loads of a plurality of different IHS configurations.

5. The IHS of claim 1, wherein the power load offset value is stored in a fan table.

6. The IHS of claim 5, wherein the fan meter is stored in the secure memory of the target IHS.

7. The IHS of claim 1, wherein the power load offset value is obtained by empirically measuring and testing the IHS at different load levels.

8. An energy estimation method for an openBMC-based firmware stack, the method comprising: When the openBMC-based firmware stack is executed on the Baseboard Management Controller (BMC), a power load offset value is applied to adjust the speed of one or more fans configured on the Information Processing System (IHS) associated with the BMC; and When the standard firmware stack is executed on the BMC, the power load offset value is applied to adjust the speed of the fan instead of the power load offset value.

9. The method according to claim 8, further comprising: One of the multiple power load offset values ​​is applied based on the current power load of the target IHS.

10. The method of claim 8, further comprising: The power load offset value was obtained using the minimum efficiency ratio of the standard performance evaluation organization SPEC.

11. The method of claim 8, further comprising: The power load offset value is obtained by averaging the power loads of multiple different IHS configurations.

12. The method according to claim 8, further comprising: The power load offset value is stored in the fan table.

13. The method of claim 12, further comprising: The fan table is stored in the secure memory of the target IHS.

14. The method of claim 8, further comprising: The power load offset value is obtained by empirically measuring the test IHS at different load levels.

15. A baseboard management controller (BMC), comprising: One or more processors and one or more memory units, the memory units including instructions that, when executed by the processor, cause the BMC to: When the openBMC-based firmware stack is executed on the BMC, a power load offset value is applied to adjust the speed of one or more fans configured on the target information processing system (IHS) associated with the BMC; and When the standard firmware stack is executed on the BMC, the power load offset value is applied to adjust the speed of the fan instead of the power load offset value.

16. The BMC of claim 15, wherein the instruction further causes the BMC to apply one of the plurality of power load offset values ​​based on the current power load of the target IHS.

17. The BMC of claim 15, wherein the power load offset value is obtained by averaging the power loads of a plurality of different IHS configurations.

18. The BMC of claim 15, wherein the power load offset value is stored in a fan table.

19. The BMC of claim 18, wherein the fan meter is stored in the secure memory of the target IHS.

20. The BMC of claim 15, wherein the power load offset value is obtained by empirically measuring the test IHS at different load levels.

Images