Two Sides of the Same Flow: Thermal Requirements and Options in OpenSFF

Introduction

Compact workstations, firewall appliances, and other small form factor systems have a self-contained approach for cooling. They have fixed design choices such as the CPU and component layout, and can design one cooling solution around those known factors. We opted to take a different approach in our open hardware standard.

OpenSFF is a nonprofit organization developing open-source hardware specifications. We define a small processing module called the Compute Node, an active electronic housing for one or more nodes called the Enclosure, and an optional node management unit called the Management Module. These three components can be combined to create a wide range of systems, from servers to edge devices, regardless of their vendors.

The Compute Node is responsible for moving heat away from its components, while the Enclosure provides active cooling through those parts. This is common in datacenter blade systems, but it offers significant advantages for single node systems as well. Instead of requiring specific passive and active cooling configurations, we define minimum airflow and thermal values to maintain interoperability.

Why do airflow requirements matter for interoperability?

Traditional hardware almost always deals with a set thermal load. The vendor knows their product’s CPU, component layout, and maximum power draw, and designs their cooling solution accordingly. Vendors of OpenSFF-compatible products can’t rely on such guarantees. Compute Nodes will have a wide range of specs and layouts, and the same can be said for Enclosures.

Instead, the Compute Node Specification defines a minimum airflow requirement of 70 m³/h (measured at the cooling shroud inlet) and a minimum static pressure requirement of 12 mmH₂O at 70 m³/h. This fixed, worst-case airflow contract doesn’t require Enclosures to know a Compute Node’s product specifications. The static pressure requirement ensures that the Enclosure’s active cooling provides at least the minimum required airflow against multiple resistance factors: the shroud inlet, heatsink fins, and any other baffles or ducting.

The Compute Node Specification also defines a cooling shroud with an inlet opening that is at least 40mm high and 96mm wide, with a 7mm inlet extension that extends beyond the PCB’s top and side edges. These measurements ensure that the shroud creates a predictable path for the airflow that the Enclosure generates regardless of the node’s heatsink placement and shroud design.

Why separate thermal transfer from airflow generation?

While it may seem simpler at first glance to just allow Compute Nodes to have their own fan, decoupling thermal transfer from airflow generation makes OpenSFF-compatible systems easily serviceable. A Compute Node can be pulled from an Enclosure without touching the fan assembly, and fans can be serviced without removing installed Compute Nodes.

The separation also makes nodes less complicated and more durable. No fan means fewer moving parts and cables that can fail. In addition, our active cooling approach allows Enclosure fans to cool other components such as the RAM, SSDs, and VRMs instead of just the CPU, for instance. Isolating active cooling to the Enclosure also relieves integrators and users from dealing with multiple airflow systems that may negatively affect each other and the system’s cooling.

How does a Compute Node control its cooling?

Separating the active cooling hardware from the Compute Node doesn't mean that the node has no say in how much cooling it receives. OpenSFF puts the node in the control cooling loop: the node generates a PWM control signal that the Enclosure uses to regulate its associated cooling fan or fan group.

This lets the node request the airflow appropriate to its thermal state without requiring the Enclosure to know the node's components or power draw. In short, the node provides the thermal control input.

This results in a defined division of responsibility: the Enclosure must be capable of delivering the required airflow, while the node can adjust the cooling it receives based on its own thermal requirements.

We’re also working on a way to allow users to control fan speed. A Full-featured Management Module, i.e, a Management Module that has its own CPU, can expose information about individual nodes to the management interface with the help of the Private Enclosure Network, a dedicated internal out-of-band management network that is present in Enclosures that have a Management Module slot.

To accomplish this, we’re developing an optional daemon called noded. When installed on a Compute Node, noded will periodically send telemetry data to the installed Full-featured Management Module. That information may include fan speeds and the CPU temperature. The goal is to not only display the temperature on the management interface, but to allow users to set a CPU temperature limit, which will influence the speed of a node’s fan or fan group. We’re also working on a way to allow users to directly set the fan or fan group’s RPM.

Why do Compute Nodes (and Management Modules) have cooling shrouds?

The cooling shroud is the bridge that connects the Compute Node and Enclosure cooling solutions. It efficiently channels air from the Enclosure across the modules’ thermal solution, prevents airflow from stagnating, and can be used to direct air over the hottest components.

The cooling shroud also serves as a layer of protection for module components, particularly during installation and removal. It also gives users another surface to handle modules besides the rear I/O shield.

Equally important, the cooling shroud helps both Enclosures and Compute Nodes fulfill their respective sides of the bargain without having their vendors directly working with each other to do so. The Enclosure promises to provide at least the minimum required airflow at our prescribed static pressure through the cooling shroud’s inlet extension. Meanwhile, the Compute Node promises that the minimum required airflow coming from the inlet will be enough for its thermal solution to keep its components adequately cooled within the specified operating temperatures.

Why can Compute Node vendors still design their own passive thermal solution?

Compute Nodes have a 120W maximum power target (MPT), but they don’t have a minimum power target. Neither does its specification dictate components or component layouts. A node vendor building an implementation that will approach the MPT might employ a large finned heatsink over the CPU, similar to those found in traditional hardware. Meanwhile, a vendor targeting a low-power node implementation might use a minimal passive solution, or if the component package makes it practical, rely largely on direct airflow over the components. Vendors can also go the laptop route and spread heat across a large fin stack using heatpipes, or connect a vapor chamber across the chips and VRMs.

The cooling shroud is also not intended to be interoperable between vendors so that they wouldn’t be constrained in their thermal designs. Just as GPUs have slightly different shrouds, Compute Nodes can have shrouds with different internal shapes or retention mechanisms. Beyond the cooling shroud, vendors are also free to use local airflow channels, baffles, or vents to direct air to the components that need them, such as VRMs or storage drives.

The primary constraint, as we mentioned, is that a fan or any active cooling component can’t be part of that solution.

Build with OpenSFF

Our standard’s airflow, static pressure, and shroud inlet requirements give vendors a dependable baseline. Any compatible Enclosure should adequately cool any compatible Compute Node within our specified operating temperatures. At the same time, we don’t dictate how vendors should meet those requirements, or what components they will fit within the available space in nodes and Enclosures. As we like to say here on our blog: as much as possible, our standard provides a floor, not a ceiling.

We encourage you to read our specifications, and we’d be grateful if you spread the word about OpenSFF. For technical clarifications and other inquiries, reach out to our development team at [email protected].