# HP llfix Onload profile controls

2026-10-07. This completes the protected launcher installation and controls
prepared in the [latency investigation](RECORD_2026-10-06_llfix-hp-onload-gap.md)
and [installer path repair](RECORD_2026-10-07_llfix-hp-installer-path-repair.md).
The user installed the three prepared launchers. Their bytes, root ownership,
modes and absence of symlinks were checked before capture. Original llfix 1.0.7
native binaries, the 39 frozen helper inputs, physical DAC namespaces and CPUs
remain pinned to the earlier [Onload generation](RECORD_2026-10-06_llfix-hp-onload.md).

## Result

Receiver polling configuration is the largest demonstrated contributor to HP's
large p99 in these controls. The receiver-only spin preset reduces p99 by
63.33%, from 18.5805 to 6.8135 microseconds. Client-only spinning reduces p99
by 12.57%. Increasing the packet pool alone produces no observed improvement.
The best profile cell, receiver-only spin plus pool, remains 2.55 times the
vendor's reported 2.663-microsecond p99. This is a diagnostic result, not a
vendor reproduction or admitted timing result.

Each table cell is the median of two independent fresh-process pairs, with
1,000 warmups and 1,000,000 measured original-program TX calls per pair.
Serialization is enabled at both endpoints. Each eight-pair placement uses
balanced order: default/spin/pool/spin+pool/spin+pool/pool/spin/default.
The three placement matrices run consecutively; their default controls are
retained separately. No quantiles are pooled across runs or rescaled.

| Preset | Client only p99 us | Both endpoints p99 us | Receiver only p99 us |
| --- | ---: | ---: | ---: |
| Default | 17.7750 | 17.2745 | 18.5805 |
| Spin | 15.5415 | 8.7870 | 6.8135 |
| Pool | 18.6365 | 18.1255 | 18.7290 |
| Spin + pool | 15.4885 | 7.9240 | 6.7895 |

Receiver-only default and spin p50 are 654 and 643 ns respectively. The mean
stays around 1.94–1.96 microseconds across the profile cells; extreme calls
still reach tens of milliseconds. The full per-pair statistics and p99 ranges
are retained in the [audited summary](evidence/llfix-hp-onload-profiles-20261007/profile-controls-summary1.json)
and [pair CSV](evidence/llfix-hp-onload-profiles-20261007/profile-controls-pairs1.csv).

## What the preset actually changed

The vendor's [pinned supplied profile](https://github.com/CorewareLtd/fix-engine-benchmarks/blob/165cc999fa283a4ead17a7b935c5d3f850fec851/common/onload_profile.cfg)
sets `EF_POLL_USEC=-1` and larger packet limits. That supplied file is not an
observation of the vendor's live stack. Our fixed launchers vary those two
inputs, preserve privilege drop and `EF_NO_FAIL=0`, and keep both TCP loopback
shortcuts disabled so the same physical SFC9220 DAC remains in use.

Live stack observations confirm the following effective options. Packet-pool
rounding from the requested 100,000 to 100,352 is retained explicitly.

| Effective option | Default | Spin only | Pool only | Spin + pool |
| --- | ---: | ---: | ---: | ---: |
| EF_INT_DRIVEN | 1 | 0 | 1 | 0 |
| EF_SPIN_USEC | 0 | 4294967295 | 0 | 4294967295 |
| EF_BUZZ_USEC | 0 | 100 | 0 | 100 |
| EF_HELPER_USEC | 0 | 500 | 0 | 500 |
| EF_MAX_PACKETS | 32768 | 32768 | 100352 | 100352 |
| EF_MAX_RX_PACKETS | 24576 | 24576 | 75000 | 75000 |
| EF_MAX_TX_PACKETS | 24576 | 24576 | 25000 | 25000 |

`EF_POLL_USEC` is a preset affecting several polling and lock behaviors,
as the [Onload guide](https://docs.amd.com/r/en-US/ug1586-onload-user/EF_POLL_USEC)
documents. These experiments isolate its placement, not each internal option.
The first client-only matrix observes live client options and the peer's
declared environment; the later matrices independently observe live options
and established accelerated sockets at both endpoints. Every pair retains
positive transmit/receive deltas on both physical ports, process identity,
namespace inode, binary hashes, process sampling and native logs.

The likely mechanism is faster receiver draining and TCP progress reducing
sender retry/flow-control delays. This is an inference from the placement
controls. The frozen SDK connector returns its socket to nonblocking mode
after connecting, then loops until the entire buffer is sent, handling errors
and partial sends. A local TX-call duration can therefore depend on receiver
progress. We have not correlated individual delayed calls with TCP ACKs,
window pressure or a particular retry. Hash-verified original connector,
reactor and socket headers are retained as supporting inputs.

## Client persistence with the receiver held spinning

A separate balanced four-pair control fixes the receiver at spin, keeps the
client at default, and changes only the client's documented
`max_serialised_file_size=0` setting. The native binaries and receiver
persistence stay the same. The disabled clients produce no message journals.

| Client persistence | Median p50 ns | Median p95 ns | Median p99 ns | Median mean ns |
| --- | ---: | ---: | ---: | ---: |
| Enabled | 650 | 2238 | 6747.5 | 1954.295 |
| Disabled | 604 | 899 | 12191 | 1949.553 |

Disabling persistence improves the median by 7.08% and p95 by 59.83%, but
worsens p99 by 80.67%. This rules out client persistence as the sole source of
the remaining p99 gap in this control. Changing sender pacing could alter
transport pressure; that explanation remains an inference. The earlier
default-receiver persistence control and its original grades remain intact.

## Verification and provenance

All 28 native pairs return zero. Four independent cold audits pass required
FIX values, groups, envelopes, checksums and contiguous owner/sequence checks:
16,016,000 persisted orders per placement matrix and 6,006,000 in the final
persistence control, totaling 54,054,000. The measured client-call count is
28,000,000. Live instrumentation makes all captures diagnostic. Quiet,
timing, vendor-reproduction and release admission remain false.

Source checkpoints are `2e7e2de447ac39a578569e7870da071a56151049` for the original
client matrix, `d363816d0069572d11512c2653367b2b59f81d46` for bilateral/receiver
placement, and `2deefb118239f6848340dd1834e1ef17297b95be` for fixed-receiver
persistence. The latter's seven qualified input bytes and modes remain
identical after integration as `b6163a0a6`. Eight focused placement controls
and then nine fixed-receiver controls pass on HP with zero skips. An initial
nonwaiting CPU-slot request returned busy without running tests; the passing
continuation waited for its high-priority shared lease. Cold audits use the
same frozen controller hash as their captures and the original frozen helper
generation.

Reported TSC conversion scales range from 3,097,000,000 to 3,106,000,000 Hz
across the 28 pairs. Exact scale equality is false. No correction is applied;
the approximately 0.29% scale spread does not explain a 63% p99 change. Vendor
hardware, compiler, Onload release, timestamp precision and runtime inputs
remain different or unverified. HP uses Gold 6254/SFC9220/GCC 11.5 and its
retained Onload build; the [website](https://www.llfix.net/) describes Gold
6134/SFN8522 PLUS/GCC 11.4.1. Its full pinned output uses Onload 8.1.3.40.

The supplied profile also requests `EF_TCP_CLIENT_LOOPBACK=1` and `EF_NAME=BM`;
HP retains both loopback shortcuts at zero and distinct process stack names.
The vendor's live topology, stack-sharing behavior and receiver configuration
are not established by its published output. The profile controls do not
qualify those remaining inputs as equivalent.

The original sender's timestamp boundary remains local encoding, message
serialization and send/enqueue, not remote delivery or RTT. The remaining
2.55-times p99 difference is unresolved. Neither the current controls nor the
vendor's p99 establish better mean or extreme-tail latency; the earlier record
retains the vendor's approximately 6-microsecond mean and 348-ms maximum.

## Retention

The original 854-file campaign and 83-file investigation seals remain intact.
The new archive retains all four captures, full journals, cold audits, source
capsules and materialized declared inputs, effective configuration evidence,
installer receipt, controls, operational scripts and summary.

An initial staging check refused Git tar's group-write mode bits. The original
script and failure log are preserved. A separate continuation verifies the
same capsule SHA256 and every member's bytes and tar mode, materializes each
declared source mode, and verifies the already staged old inputs without
overwriting them. This affects only disposable evidence copies. A fixed
operational manager executes two read-only cold auditors under one shared
lease, forwarding its lease descriptor explicitly; its source and result are
retained. Native pairs run sequentially.

Archive verification and the exact Git metadata selection are recorded in
the [selection manifest](evidence/llfix-hp-onload-profiles-20261007/selection-manifest.json).
The 458-file seal covers 44,308,227,540 bytes. Its compressed archive is
783,976,852 bytes. HP and BEELINK2 independently stream and verify every
member's SHA256, size and mode; their passing receipts are identical.
Archive SHA256:
`8262c203e2397ab71e007d2fe1952dc51b67579aae5e6f344942187d0adcab94`.
Seal SHA256:
`e3e411ce846c92385328e58fa756d395dcb3897f33c18913d06347d1130dfee9`.
The Git selection contains 207 exact sealed metadata files plus the seal and
separately named operational receipts/scripts. Full journals and source tar
capsules stay in the compressed archive.
Raw journals live in the sealed `hp-onload-gap-profiles1.tar.gz` archive under
`~/archive/libhft/codex-llfix-reference-20261007/` on HP and BEELINK2. Stage 2
adapters, prepared rankings, SDK source, full-session fixtures and installed
native generations are unchanged.