Quick Answer
A CRPS redundant power supply is compatible only when the modules, power distribution board or backplane, chassis, control logic, management firmware, AC inputs, and redundancy policy have been validated as one subsystem. Equal wattage and a CRPS label do not prove interchangeability. The applicable Common Redundant Power Supply (CRPS) Base Specification revision may define a mechanical format, mating-interface framework, and supported electrical or control provisions, but individual implementations can differ in feature selection, standby capability, airflow, derating, PMBus behavior, and platform approval. Procurement needs the exact specification title, document revision and date, module part and hardware revision, interface records, approved chassis population, and firmware requirements. An undocumented replacement is an engineering change, even if it fits the bay and powers the server.
What the CRPS Label Establishes—and What It Does Not
CRPS commonly refers to the Common Redundant Power Supply (CRPS) Base Specification document family associated with Intel server-system infrastructure guidance. A defensible conformance record identifies the exact controlled document by title, revision, publication date, and document number where one is assigned. “CRPS compatible,” “CRPS form factor,” or a reseller’s product-family description is not equivalent to that evidence.
The revision matters because CRPS is not one timeless connector-and-feature definition. A module designed against one revision must not be assumed interoperable with a backplane designed against another. Engineering must compare the applicable requirements and documented implementation choices; a newer revision is not automatically backward-compatible, and a shared external appearance does not settle the question.
The CRPS document applicable to a candidate may control or constrain provisions such as:
- the named mechanical envelope and blind-mate interface arrangement;
- module insertion, extraction, keying, and retention provisions;
- the contact framework and intended mating sequence;
- main-output, return, standby, presence, enable, status, and sharing interface definitions that apply to that implementation;
- electrical timing or hot-plug provisions included by the cited revision;
- supported communication-interface requirements where the implementation claims those features.
Those provisions still do not turn every CRPS module into a universal spare. The specification may offer options, identify multiple physical formats, or leave parameters to the PSU and platform designer. The exact wattage, available output at a given AC input, standby capacity, airflow direction, acoustic policy, fan response, telemetry set, management address behavior, fault thresholds, transient limits, and approved mixed-module population remain product- or platform-specific unless the controlled documentation says otherwise.
There is also a crucial allocation question: which device performs each function? Output isolation may be implemented inside the PSU module, while current-share coordination can involve module circuitry and backplane interconnections. Presence signals may terminate at system logic. Alarm interpretation and redundancy policy may reside in the BMC. Distribution protection may be located on the power distribution board. No generic CRPS description can substitute for the platform schematic, interface definition, and approved-parts record.
Equal-Wattage CRPS Candidates Can Be Functionally Different
The following matrix shows why wattage is only a screening attribute. Candidate A and Candidate B are hypothetical equal-rated modules; the entries describe evidence to compare, not claims about a commercial product.
| Comparison point | Hypothetical Candidate A | Hypothetical Candidate B | Compatibility decision |
|---|---|---|---|
| CRPS evidence | Supplier provides the exact CRPS Base Specification revision and a compliance record | Listing says only “CRPS form factor” | Candidate B lacks enough evidence to establish revision-level interoperability |
| Physical format | Controlled drawing matches the approved envelope, guide features, latch, and connector position | Front face and width appear similar, but insertion depth and keying are undocumented | Visual similarity does not prove seating, retention, or contact engagement |
| Connector implementation | Power, return, standby, presence, control, status, sharing, and management contacts are mapped to the platform interface | Uses a visually compatible blind-mate connector with no controlled contact comparison | Do not energize Candidate B until every used contact and mating sequence is reconciled |
| Standby capability | Voltage, available current, timing, and protection meet the server requirement | Main output rating matches, but standby data is absent | Equal main wattage cannot compensate for an inadequate or incompatible standby output |
| Control and sharing | Enable, power-good, fault, presence, current sharing, and isolation behavior are platform-approved | Supports similarly named signals but with unconfirmed levels, timing, or response | Signal names alone do not establish electrical or timing compatibility |
| Airflow | Airflow direction and fan control match the chassis cooling design | Opposite direction or undocumented fan behavior | A mechanically fitting module can recirculate hot air or disrupt chassis pressure |
| Input conditions | Required output is documented at the deployment’s AC voltage and environmental limits | Same headline wattage, but derating conditions are unknown | Compare available output at actual input, temperature, altitude, and airflow conditions |
| Management behavior | BMC firmware recognizes identity, status, supported telemetry, and events | PMBus is advertised, but commands, addressing, and OEM extensions are unspecified | PMBus presence does not prove management interoperability |
| Platform approval | Exact part and revision appear in the server’s approved configuration record | No platform cross-reference or completed qualification report | Candidate B remains an unqualified engineering substitution |
A higher-wattage candidate can fail the same comparison. Installing it does not raise server capacity unless the PDB, contacts, downstream conductors, cooling system, firmware policy, and AC input support the increase. The usable limit is the lowest documented limit in the complete input-to-load path.
The Backplane Is an Active Compatibility Boundary
“Backplane” is sometimes used loosely for the assembly receiving the modules. Depending on the server, it may be a connector board, a power distribution board, or part of a larger distribution and control assembly. Its role is platform-dependent. It can route high-current output and returns, carry standby power and signal contacts, connect sharing or management lines, and deliver power to downstream converters or bus bars. Protection, isolation, sequencing, and policy functions may be split among the modules, this assembly, and system control logic.
Compatibility therefore requires more than matching the visible connector shell. Controlled drawings and interface records need to establish contact location, assignment, plating or mating requirements where specified, engagement depth, insertion sequence, and the functions the platform actually uses. A module that stops short of full engagement can appear latched while creating excessive contact resistance. A module with a different signal implementation can deliver main output yet leave the server unable to sequence, monitor, or service it correctly.
The PDB also has finite current and thermal capability. Its connector contacts, copper paths, protection devices, bus structure, and downstream interfaces may be qualified only for particular PSU populations and server power envelopes. A replacement module’s rating is permission for that module to deliver up to a documented limit under stated conditions; it is not permission for the server to draw that amount through an unqualified backplane.
Main Output and Standby Are Separate Interfaces
The main output rating dominates product listings, but standby operation can determine whether the server starts or remains manageable while the main output is disabled. Depending on the implementation, standby power may support the BMC, module discovery, event logging, power-state control, or sequencing circuitry.
A candidate with sufficient main-output wattage can still be incompatible if its standby voltage, current capability, startup timing, fault response, or contact implementation does not meet the platform requirement. Symptoms may include incomplete BMC initialization, intermittent module discovery, a failure to enable the main output, or alarms that depend on which bay is populated.
Standby operation also changes during service events. AC loss, module extraction, insertion, and restoration can alter presence and standby states before normal sharing resumes. Cold-start success therefore does not demonstrate live-service compatibility.
Two Modules Do Not Eliminate Every Single Point of Failure
Redundancy needs to be stated by layer. A server can have redundant PSU modules without having redundant AC sources or a fault-tolerant distribution board.
- PSU-module redundancy means the required server load remains supported after loss or removal of one module.
- AC-feed redundancy means the design tolerates loss of one intended upstream source, branch circuit, cord path, or rack power path within the declared failure model.
- Distribution-path fault tolerance concerns the PDB, common output bus, connector assembly, and downstream conductors. A shared component can remain a common failure point even when two modules use separate AC feeds.
For example, two independently fed CRPS modules can tolerate one failed feed if either module can carry the server. They may still both connect to one PDB and one common downstream bus. A PDB fault that opens or shorts that shared path can defeat both modules. Calling the server “dual redundant” without naming the protected failure states overstates what the architecture provides.
Installed Capacity Is Not Surviving Capacity
Consider a clearly hypothetical CRPS redundant power supply configuration:
- two identical, platform-approved modules;
- documented output capability of 1,600 W per module under the intended input and thermal conditions;
- a 1,250 W sustained server DC load;
- a credible 1,450 W workload excursion;
- an approved 1+1 operating mode.
With both modules operating, idealized equal sharing of the sustained load would be:
Approximate load per module = 1,250 W ÷ 2 = 625 W
That result describes the normal state, not redundant capacity. After one module or one associated feed is lost:
Post-failure load per survivor = 1,250 W ÷ 1 = 1,250 W
The installed nameplate total is 3,200 W, but the protected 1+1 load is bounded by one surviving module and one surviving power path. The 1,450 W excursion can be accepted only if its duration and profile stay within the documented duration-dependent limits of the module, PDB, and server. Nameplate wattage alone provides no evidence about transient acceptance.
If sustained demand rises to 1,750 W, both modules might support it in a combined-capacity mode approved by the platform. The configuration would not preserve 1+1 protection at that load because one 1,600 W survivor is insufficient. The word “redundant” is meaningful only when accompanied by the protected load and failure model.
Actual AC Demand Follows Load and Losses
PSU rating is output capacity, not continuous consumption. Actual server demand depends on processors, accelerators, memory, storage, fans, firmware limits, utilization, and workload transitions. Rack planning uses validated DC demand and measured or documented conversion behavior—not the sum of PSU labels as an assumed continuous load.
For illustration only, if the surviving module supplies 1,250 W DC at an assumed 92% efficiency:
AC input power = DC output ÷ efficiency
AC input power = 1,250 W ÷ 0.92 ≈ 1,359 W
The efficiency value is not attributed to any product. Real input power requires verified efficiency at the relevant input and load, while AC current also depends on voltage, power factor, and source conditions. The surviving branch and PDU path must accommodate the post-failure demand. A rack design based only on the half-load normal state can preserve the server’s DC capacity yet overload the remaining AC path after a feed failure.
Sharing, Takeover, and Isolation Are Different Tests
Current sharing helps distribute normal load and heat, but an apparently balanced pair does not prove redundancy. Qualification separates three behaviors:
- Steady-state sharing: both healthy modules divide load within the platform’s specified deviation across the relevant operating range.
- Dynamic takeover: the surviving module accepts the transferred load while common-bus voltage remains within the server’s allowed excursion and recovery limits.
- Fault isolation: an unpowered, internally failed, or extracted module does not backfeed, pull down, or destabilize the common output.
The allocation of these functions is implementation-specific. Isolation circuitry may be internal to each module, while share signals pass through the PDB. The system controller may alter power limits or fan behavior after a fault. Consequently, a module-level report does not by itself qualify the complete server transition.
Mixed modules require particular caution. Two equal-wattage units can have different regulation setpoints, sharing responses, firmware identities, fan curves, fault timing, or transient behavior. One unit may consistently carry more load, increasing its temperature and reducing the intended margin. Unless the platform explicitly approves the mixed pair, it is a new configuration requiring the same failure-state testing as any other engineering change.
PMBus Does Not Create Universal CRPS Management Compatibility
A CRPS-labeled module may expose PMBus management, but the presence of that interface does not guarantee a universal command set or BMC interpretation. Supported commands, telemetry fields, units, update rates, accuracy, status-bit use, page behavior, addressing, inventory data, and manufacturer-specific extensions can differ. Some functions may be optional or unused by the platform.
Management qualification needs to establish what the server actually expects:
- module discovery and address behavior in each bay;
- identity and revision fields used for inventory or matching policies;
- supported input, output, temperature, fan, and fault telemetry;
- distinction among AC loss, output fault, module removal, and communication loss;
- alarm assertion, event logging, and clearing behavior;
- firmware rules for mixed capacities, identities, or hardware revisions;
- behavior after approved BMC or system-firmware updates.
Successful BMC discovery proves only that some communication occurred. It does not prove electrical compatibility, correct telemetry, load sharing, or safe failover. Conversely, a module may continue powering the bus while producing unsupported inventory or alarm behavior. That state can be operationally unacceptable because fleet software may report redundancy when a feed has failed—or generate false replacement tickets for healthy hardware.
Hot-Swap Compatibility Exists Only During the Transition
A handle and blind-mate connector make extraction possible; they do not prove safe hot-swap. During removal, the departing module’s contacts and control states must disengage in the intended order, the survivor must take the full load, and bus voltage must stay inside the server’s documented limits. During insertion, inrush and precharge behavior must remain within subsystem limits, contacts must mate in the designed sequence, and the new unit must initialize without disturbing the active output.
Airflow is part of this event. Removing a module can open an air path or change pressure through the PSU cage. The platform may require a replacement module or approved filler within a defined service process. After insertion, the BMC must identify the module, clear appropriate events, and restore the approved sharing state.
“Hot-swappable” also does not mean removable at any workload. Before extraction, the remaining module, AC source, and downstream path need enough documented capacity for the current sustained load and credible transition. Platform service instructions take precedence over informal practices.
The Approval Package Must Name Exact Revisions
A purchasing description should be precise enough to prevent substitution based on appearance or wattage. A complete approval record contains:
| Record | Required evidence |
|---|---|
| CRPS basis | Exact Common Redundant Power Supply (CRPS) Base Specification title, revision, date, document identifier where available, claimed options, and documented deviations |
| Module identity | Exact part number, relevant hardware revision, supplier datasheet, and platform approval or completed qualification report |
| Mechanical interface | Controlled module and chassis drawings covering envelope, guides, keying, depth, latch, handle clearance, connector location, and airflow direction |
| Electrical interface | Controlled contact mapping for main output, returns, standby, presence, enable, status, sharing, and management functions used by the server |
| Operating envelope | Available sustained and duration-dependent output under intended AC input, inlet temperature, altitude, and airflow conditions |
| PDB capability | Approved module population, connector and distribution limits, protection topology, and downstream power-path constraints |
| System control | BMC and firmware versions, supported inventory and telemetry behavior, alarms, matching policy, and recovery logic |
| Redundancy claim | Protected load and explicit failure states for module, feed, and shared distribution components |
An exact platform approval is stronger than a reseller cross-reference. Controlled drawings are stronger than photographs. A no-load power-on test is weaker than qualification in the intended chassis, firmware, input topology, environment, and workload envelope.
Acceptance Testing Must Produce Measurable Evidence
Pass limits must come from the applicable CRPS revision, module documentation, PDB requirements, and server platform specification. The test plan can define measurements before testing without inventing acceptance thresholds.
- Freeze the configuration. Record PSU part and hardware revisions, CRPS document basis, PDB and chassis revisions, firmware versions, bay assignment, AC-feed topology, airflow orientation, instrumentation, workload, and redundancy mode.
- Inspect mechanical mating. Document guide alignment, full seating, latch engagement, handle clearance, connector condition, and repeatable insertion in both bays.
- Operate every independent path. Run from each module, each bay, and each intended AC source separately. This exposes a weak bay, cord path, or module hidden during dual operation.
- Measure steady-state sharing. At representative loads, record each module’s output contribution and calculate current-share deviation using the platform’s specified method. Also record common-bus voltage, temperatures, fan behavior, and management readings.
- Remove one AC input. Capture bus-voltage excursion, minimum and maximum voltage, recovery or takeover duration, surviving-module loading, alarm assertion time, event identity, and workload continuity.
- Perform approved live extraction. Use suitable instrumentation to observe the common bus during removal. Record voltage excursion, fault isolation behavior, alarm timing, and any server reset, throttling, or error event.
- Measure insertion behavior. During reinsertion, observe inrush current or the platform-approved proxy, bus disturbance, initialization time, inventory recognition, alarm clearing, and return to the permitted current-share range.
- Exercise documented transient profiles. Apply duration-defined workload changes relevant to the deployment. Record bus response and module loading against platform limits; do not infer transient capability from wattage.
- Observe thermal states. Record PSU inlet and exhaust observations, module-reported temperatures where validated, fan response, connector or PDB hot spots using approved methods, and behavior after failover at the worst authorized environmental condition.
- Repeat symmetrically. Swap bays or modules as the test design permits and repeat feed loss, extraction, and reinsertion. One successful direction does not prove both paths.
Alarm timing deserves explicit treatment. An alarm that appears eventually may still be too late for automation, while an event that never clears can leave operations unable to confirm restored redundancy. Likewise, management telemetry can support testing only after its accuracy and update behavior have been correlated with suitable instruments.
The acceptance report should preserve raw measurements, specified limits, pass/fail rationale, and any deviations. “Server stayed on” is not sufficient evidence if the bus exceeded an undocumented boundary, the survivor entered an unsustainable thermal state, or the BMC failed to report that redundancy was lost.
The Conditional Decision for a CRPS Redundant Power Supply
A CRPS redundant power supply qualifies as a redundant server subsystem only if the exact modules conform to the documented CRPS revision and implementation used by the platform, mate correctly with the chassis and PDB, satisfy main and standby requirements, share and isolate faults as specified, communicate correctly with the installed firmware, and complete removal and reinsertion within documented electrical and thermal limits.
If two modules merely have equal wattage, similar dimensions, or a generic CRPS description, compatibility remains unproven. If one approved survivor can carry the declared sustained and duration-defined transient load under actual input and environmental conditions, both AC paths meet the intended failure model, shared PDB risks are explicitly accepted, and measured takeover, alarms, inrush, sharing, and thermal behavior pass platform limits, the pair can legitimately be operated as one CRPS redundant power supply system.
