1# Control.ThermalMode dbus interface with Supported and Current properties 2 3Author: 4 Matthew Barth !msbarth 5 6Primary assignee: 7 Matthew Barth !msbarth 8 9Other contributors: 10 None 11 12Created: 13 2019-02-06 14 15## Problem Description 16An issue was discovered where the exhaust heat from the system GPUs causes 17overtemp warnings on optical cables on certain system configurations. The 18issue can be resolved by altering the fan control application's floor table, 19effectively raising the floor when these optical cables exist but an interface 20is needed to do so. Since the issue revolves around the optical cables 21themselves, where no current mechanism exists to detect the presence of the 22optical cables plugged into a card downwind from the GPUs' exhaust, 23an end-user must be presented with an ability to enable this raised floor 24speed table. 25 26## Background and References 27The witherspoon system supports pci cards that could have optical cables 28plugged in place of copper cables. These optical cables can report overtemp 29warnings to the OS when high GPU utilization workloads exist. When this occurs 30with low enough CPU utilization, the fans could be kept at a given floor speed 31that sufficiently cools the components within the chassis, but not the optical 32cables with the slow moving hot exhaust. 33 34Without an available exhaust temp sensor, there's no direct way to determine 35the exhaust temp and include that within the fan control algorithm. A similar 36issue exists on other system where mathematical calculations are done based on 37the overall power dissipation. 38 39Mathematical calculations to logically estimate exit air temps: 40https://github.com/openbmc/dbus-sensors/blob/master/src/ExitAirTempSensor.cpp 41 42## Requirements 43Create the ability for an end-user to enable the use of a thermal control mode 44other than the default. In this use-case, the mode is specific to an 45undetectable configuration that alters the fan floor speeds unrelated to 46standardized profile/modes such "Acoustic" and "Performance". Once the end-user 47selects a documented mode for the platform, the thermal control application 48alters its control algorithm according to the defined mode, which is 49implementation specific to that instance of the application on that platform. 50 51## Proposed Design 52Create a Control.ThermalMode dbus interface containing a supported list of 53available thermal control modes along with what current mode is in use. 54Initially the current mode would be set to "Default" and the implementation 55of the interface would populate the supported list of modes. 56 57As one implementation, phosphor-fan-presence/control would be updated to extend 58this dbus interface object which would fill in the list of supported modes 59from its fan control configuration for the platform. Once the fan control 60application starts, the interface would be added on the zone object and 61available to be queried for supported modes or update the current mode. 62An end-user may set the current mode to any of those supported modes and the 63current mode would be persisted each time it is updated. This is to ensure 64each time the fan control application zone objects are started, the last set 65control mode is used. 66 67## Alternatives Considered 68Mathematical calculation to create a virtual exhaust temp sensor value based 69on overall power dissipation. However, in the witherspoon situation, using 70this technique would not be reliable in adjusting the floor speeds for only 71configurations using optical cables. This would instead present the possibility 72of raising floor speeds for configurations where its unnecessary. 73 74## Impacts 75The thermal control application used must be configured to provide what thermal 76control modes are supported/available on the interface as well as perform the 77associated control changes when a mode is set. 78 79## Testing 80Trigger the use of an alternative fan floor table based on the thermal control 81mode selected on a witherspoon system. 82