The RHEL Real Time kernel, priced for the tail.

The RHEL Real Time kernel is the low latency variant of the Linux kernel that Red Hat delivers through a separate subscription line on top of the base RHEL subscription. The kernel package is built from the upstream PREEMPT_RT tree, the userland is the same as the standard RHEL release, and the difference shows up where it matters: scheduler determinism, interrupt handling, and tail latency on workloads that price the worst case over the average case. The subscription is sold per host, priced separately from the base RHEL line, and applies to every host that boots into the Real Time kernel.1

The counting unit follows the base RHEL line. A two socket physical host with a base Real Time subscription consumes one Real Time line. A virtualised host with a Virtual Datacenter base RHEL line carries one Real Time line per guest that boots into the Real Time kernel, not per hypervisor. The Real Time line does not inherit the unlimited guest mechanic of the Virtual Datacenter base; the interaction parallels the one walked in the High Availability add on licensing note. The reading is read against the audit ready artifact, which is the boot record on each host showing which kernel the host last booted.

The Real Time line is independent of the High Availability add on and the Resilient Storage add on. A Real Time host that is also a Pacemaker cluster member carries the Real Time line, the base RHEL line, and either the High Availability line or the Resilient Storage line, depending on the cluster topology. A Real Time host that runs no cluster stack carries the Real Time line and the base RHEL line alone. The bundling logic that holds on the SAP platform lines does not hold here; the procurement register should reflect each line separately.

Three workload families recur as the structural use cases for the Real Time kernel across signed engagements. The buyer side reading begins with the family, not the kernel; the kernel is the consequence of the family, and the procurement register should follow.

The first family is the telecommunications data plane. Mobile core network functions, packet processing pipelines, and software defined radio components run on hosts where the tail latency of the kernel scheduler determines the user experience. The standard kernel produces occasional millisecond spikes that translate into call drops, jitter, and out of band failures at scale. The Real Time kernel constrains those spikes within a tighter envelope. The reading on the telco estate is treated in the broader telecom audit considerations.

The second family is the financial markets trading and risk pipeline. Order matching engines, market data fan out, and tick to trade pipelines run on hosts where a microsecond of jitter translates into measurable revenue. The Real Time kernel reduces jitter at the cost of average throughput; the trade off is the right one for the workload. The interaction with the broader treatment of finserv specific audit exposure sits in the parallel work on industry vertical audits.

The third family is industrial control and embedded edge. Manufacturing line controllers, robotics platforms, and broadcast equipment run on hosts where a missed deadline produces a physical consequence. The Real Time kernel provides the deadline guarantees the workload requires. The reading interacts with the edge variant of RHEL, discussed in RHEL for edge and embedded licensing, where the kernel choice and the edge subscription model intersect.2

Two drift patterns recur on Real Time kernel readings across signed engagements. The patterns are mirror images of one another, and an estate frequently runs both at once.

The first drift is the kernel that quietly reverted. A host was originally provisioned with the Real Time kernel for a latency sensitive workload; an operations team rebuilt the host eighteen months later from a standard kernel image; the procurement register continues to carry the Real Time line for the host. The boot record on the host shows the standard kernel; the audit reading frames the line as overpayment for the period of standard kernel operation; the renewal cycle is the natural moment to retire the line. The pattern is the most common single finding on Real Time readings in the practice's observation and sits inside the broader treatment in recoverable over entitlement cost.

The second drift is the kernel that quietly arrived. A host was provisioned with the standard kernel; an engineering team rebooted into the Real Time kernel during a latency tuning exercise eight months ago; the procurement register continues to carry only the base RHEL line. The boot record shows the Real Time kernel; the audit reading frames the host as unentitled Real Time for the period of operation; the remediation is to attach the line going forward and to treat the period of past operation as the basis for any settlement reading. The reading interacts with the broader audit defense treatment in audit defense.3

The reading on the mixed estate combines both patterns. The buyer's procurement register carries a constant Real Time line count year over year; the host inventory of Real Time kernel boots fluctuates as workloads move between kernels; the gap between the two grows because the procurement register does not see the boot record on each host. The renewal cycle is the moment to walk the boot record and to retire or attach the line accordingly.

The audit reading on Real Time licensing rests on the boot record. The boot record is the artifact that names the kernel the host last booted into; on a healthy estate the artifact is one column in a host inventory and is regenerated at each reboot. The audit reads the boot record against the procurement register and against the host inventory; the three reconcile when every host that booted into the Real Time kernel carries a paid Real Time line.

Three inconsistencies recur. The first is the host that booted into the Real Time kernel but is missing the Real Time line; the reading is exposure for the period of Real Time operation. The second is the host that carries the Real Time line but booted into the standard kernel; the reading is overpayment for the period of standard kernel operation. The third is the host that booted into the Real Time kernel intermittently, switching between standard and Real Time across reboots; the reading is the most procedurally awkward and the audit treatment varies. The practice has settled this pattern by treating the period of Real Time operation as the basis for the line, with the procurement register reflecting the line on a continuous basis going forward.

The reading is also where the practice observes the most useful telemetry overlap with the broader Red Hat Insights reading. Insights captures the kernel version on each registered host, and the reading provides the same boot record artifact at scale. The interaction is treated in the Red Hat Insights data and audit note. The boot record is the audit ready artifact for Real Time licensing. The narrative the buyer provides about workload intent is not, regardless of how well documented the intent may be.4

The renewal posture on Real Time has three habits. The list is short by design; the same three habits, applied honestly, retire the drift in most estates within a single renewal cycle.

The first habit is the boot record inventory. A short artifact, owned by the operations team, that names every host and the kernel the host last booted. The artifact is reviewed quarterly and the entitlement register is reconciled against it at each renewal cycle. The artifact sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the cluster intersection. The Real Time host list is read against the Pacemaker cluster member list. A Real Time host that is also a cluster member carries both the Real Time line and the High Availability or Resilient Storage line, and the procurement register reflects both. The intersection is small on most estates and is the source of compounding overpayment when the procurement register treats the lines as alternatives rather than as parallel requirements.

The third habit is the renewal cycle retirement. Real Time lines on hosts that have reverted to the standard kernel are retired at the renewal cycle; Real Time lines for hosts newly booting into the Real Time kernel are attached. The retirement and the attachment frequently fund one another on the same estate, and the engagement reads as net positive on the trailing twelve month basis. The pattern overlaps with the broader treatment of renewal cycle discipline in renewal negotiation and with the sibling reading on the related platform line in RHEL for SAP Applications licensing.

For the practice hub, see the RHEL practice. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.