Latency-first kernel profile
HFTKernel enables high-frequency timer behavior, preemption, nohz-full capability, RCU callback offload support and high-resolution timing primitives where available.
Linux 7.1 • HFT profile • AWS EC2 / bare metal
A purpose-built Linux kernel for High Frequency Trading systems.
HFTKernel is a reproducible Linux kernel build for latency-sensitive trading infrastructure. It is tuned for isolated execution cores, controlled interrupt placement, RTLA-based measurement and predictable tail latency under server workloads.
Designed for trading gateways, feed handlers, exchange connectivity, replay labs and cloud/bare-metal latency engineering.
Representative validation snapshot
7.1.1-hftkernel release tested
~5,000 : 2housekeeping IRQs vs isolated CPU IRQs per sample window
~3.3 GHzbusy frequency observed on AMD EPYC while active
0.01–0.02%isolated CPU busy rate when idle
Measured in an AWS EC2 2-vCPU isolation profile using turbostat, interrupt counters and RTLA. Values are platform-specific examples, not a universal guarantee.
What HFTKernel is
HFTKernel is a specialized Linux kernel package and tooling set for teams that need measurable latency behavior, not a general-purpose server default.
Cloud and hardware baselines
Builds can start from an AWS kernel config or a hardware server config, then apply the HFT profile, compiler options and optional patch sets.
Measured, not guessed
The workflow uses RTLA timerlat/osnoise, turbostat, interrupt counters, ENA statistics, TCP counters and application-level p99/p99.9 data.
Deployable artifacts
DEB, RPM and TGZ outputs are produced for controlled installation, rollback planning, validation and reproducible release management.
Who it is for
HFTKernel is built for infrastructure teams where latency spikes, IRQ leakage, socket stalls or noisy housekeeping work can directly affect trading quality.
- High Frequency Trading infrastructure teams
- Order-entry gateways and execution connectivity systems
- Feed handlers, replay engines and packet capture systems
- AWS EC2 / Nitro latency labs
- Bare-metal exchange connectivity environments
- Teams that need repeatable kernel candidates with clear measurement criteria
hftkernel/releases
gated access
Kernel7.1.x-hft
ArtifactsDEB • RPM • TGZ
MeasurementRTLA • turbostat • ENA counters
TargetsAWS EC2 • Ubuntu • bare metal
Download packages
Access is provided by request so that the package set matches your platform, Ubuntu version, AWS or hardware baseline, rollback plan and Secure Boot policy.
| Type | Package | Platform | Purpose | |
|---|---|---|---|---|
| DEB | linux-image-7.1.1-hft_1_amd64.deb |
Ubuntu 22.04/24.04, AWS EC2 x86_64 | Kernel image for isolated trading cores | Request |
| DEB | linux-headers-7.1.1-hft_1_amd64.deb |
Ubuntu 22.04/24.04, build hosts | Headers for modules and build tooling | Request |
| DEB | hft-rtla-7.1.1-hft_1_amd64.deb |
Ubuntu 22.04/24.04 | RTLA timerlat and osnoise measurement tools | Request |
| RPM | kernel-hft-7.1.1-1.x86_64.rpm |
ALT/RHEL-like test hosts | RPM build for hardware validation labs | Request |
| TGZ | hftkernel-7.1.1-hft-bundle.tgz |
Source/config bundle | Config, scripts, checksums and release notes | Request |
How results are measured
Every candidate kernel is evaluated with the same boot parameters, instance type, NIC layout and workload. The goal is a small set of human-readable pass/fail and tail-latency metrics.
| Area | Method | Readable result |
|---|---|---|
| CPU isolation | turbostat and /proc/interrupts on housekeeping and isolated CPUs | Example: housekeeping CPU handled roughly five thousand IRQs per sample window while the isolated CPU saw only about two. |
| Active frequency | turbostat Busy%, Bzy_MHz and TSC_MHz | Example: the isolated CPU stayed nearly idle when no trading process was pinned, but active samples showed roughly 3.3 GHz busy frequency. |
| Scheduler and timer noise | RTLA timerlat and osnoise on the isolated CPU | Report max latency, spike count and whether the candidate is better, neutral or rejected versus baseline. |
| Network stability | ENA driver stats, softnet counters, TCP retransmits and socket state | Pass condition: no new RX/TX drops, no softnet pressure and no retransmit regression versus the standard server kernel baseline. |
| Application path | Application p50/p95/p99/p99.9, sequence gaps, reconnects and processing-loop stalls | Adopt only if tail latency improves or stays neutral with zero gap/reconnect regressions. |
Decision rule: keep the simpler kernel if the candidate is within ±5% of baseline. Adopt HFTKernel when p99/p99.9 improves and counters remain clean. Reject any candidate with drops, gaps, reconnects, IRQ leakage or worse tail latency.
Compared with standard server distribution kernels
HFTKernel is not a general-purpose server default. It is designed for controlled server deployments where CPU roles, IRQ placement and workload boundaries are known.
| Criterion | Standard server distribution kernel | HFTKernel |
|---|---|---|
| Primary goal | Broad server compatibility, stable defaults and general fleet safety | Latency predictability for tightly controlled trading infrastructure |
| CPU model | General scheduling across all CPUs | Housekeeping CPUs separated from isolated trading CPUs |
| Interrupt path | Distribution defaults, often appropriate for general server work | Explicit IRQ, kthread, RCU callback and systemd affinity strategy |
| Network path | General-purpose TCP and NIC behavior | ENA-aware deployment, queue tuning workflow and TCP counter validation |
| Measurement | Standard monitoring and logs | RTLA, turbostat, interrupt counters, ENA statistics and app-level tail latency |
| Deployment model | Distribution-managed package lifecycle | Controlled candidate packages with explicit rollback to the standard server kernel |
Deployment workflow
- Baseline. Capture the current server kernel, boot line, CPU topology, ENA/NVMe state and application latency metrics.
- Build. Create a cloud or hardware package using the appropriate baseline config and package format.
- Install. Install image, headers and RTLA package. Keep the standard distribution kernel as a boot fallback.
- Measure. Run RTLA, turbostat, interrupt accounting, network counters and the real trading workload.
- Decide. Promote only if tail latency improves without drops, retransmits, gaps or operational regressions.
Recommended validation window
Each kernel candidate should run the same 30–60 minute application test plus a 10 minute RTLA isolation pass.
- Boot and network sanity
- RTLA timerlat/osnoise on isolated CPU
- Interrupt and softirq accounting
- ENA and TCP before/after counters
- Application p99/p99.9 and gap report
FAQ
Is HFTKernel a replacement for the standard server kernel?
Not automatically. We recommend keeping the standard distribution kernel as the GRUB fallback and promoting HFTKernel only after measured validation on the target workload.
Can it run on Ubuntu 24.04?
Yes. Upstream-style DEB packages can be installed on Ubuntu 22.04 or 24.04. For production testing, build with the baseline config from the target Ubuntu version.
Do I need Secure Boot?
Most custom kernel deployments use unsigned packages and keep Secure Boot policy explicit. If Secure Boot is required, plan for module and kernel signing before rollout.
How is it different from a standard server kernel?
A standard server kernel is built for wide compatibility and safe defaults across many workloads. HFTKernel narrows the target: isolated CPUs, controlled IRQ paths and measurable tail-latency behavior for trading systems.
Why are downloads gated by a contact form?
The correct artifact depends on Ubuntu version, AWS or hardware baseline, CPU family, Secure Boot policy and rollback requirements. The form prevents mismatched packages from being installed on latency-critical systems.
Request package access or deployment guidance
Tell us your platform and objective. We will respond with the correct package set, installation notes and a measurement plan.
Ubuntu 22/24AWS EC2DEB/RPM/TGZRTLAHigh Frequency Trading