# HP llfix receiver-buffer and rate preparation

2026-10-07. Preparation for the next controls after the
[TCP tail investigation](RECORD_2026-10-07_llfix-hp-tcp-tail.md).
This checkpoint qualifies a separate sender on kernel loopback and prepares
fixed receiver-buffer launchers. It contains no new physical performance result,
quiet timing, vendor reproduction, Stage 2 or release admission.

## What is prepared

Source `9338947d1da982a9c762bbc55a97361f4bf9f6a8` is retained on
`s/codex-llfix-reference-load-controls-source-20261007`. Its runnable source
capsule contains 60 exact files, including the original framework, new private
controls and unchanged hft-bench headers. The
[diagnostic recipe](../../bench/llfix_reference/diagnostics/load_controls/README.md)
documents measurement boundaries and execution.

The new `paced_tx.cpp` preserves the reference framework's complete timed
`TxTask` byte for byte. The existing runner provides pacing outside the SDK
service-time probe. Requested rates are 0, 100000, 250000, 500000 and 750000
calls/second. Full primary and scheduler-delay series are retained in CSV and
HFTBRW; cold checks independently recompute counts, quantiles, actual maxima,
means, achieved rate and clamping disclosure. Achieved rate includes measured
pass pacing/runner time and excludes setup, connection and warmup. This remains
the re-anchoring service-time model, not a coordinated-omission-free arrival
benchmark or an individual remote-delivery latency measurement.

The receiver profiles keep spin enabled and request default, 262144 or 1048576
bytes through `EF_TCP_RCVBUF`. Onload doubles the requested buffer size; these
are nominal 4x/16x controls against the previously observed approximately
131400-byte receive buffer. The original SDK's accepted-socket config does not
apply its receive-buffer field. New observations must verify effective Onload
options and retain actual socket sizes independently of nominal requests.

The payload is `/usr/local/libexec/llfix-reference-hp-load-v1-7fc38f148858`.
Four new fixed namespace launchers select plain/spin/rx4/rx16. Both TCP loopback
shortcuts remain disabled; CPUs stay client 17/peer 16 on the physical SFC9220
link. Previous SDK sources, native payloads/launchers, raw campaigns, Stage 2
and shared helpers are unchanged.

## Functional qualification

HP uses the retained GCC 11.5 compiler (SHA256
`fc1ea664a2a85c301fef71284f5e4906eaeb40a40c5225f9b0ac1aae10b00c2e`),
unmodified bundled llfix 1.0.7 source and exact prior hft-bench headers. The
build retains C++17/NDEBUG/O3/no-rtti/native tuning and pthread flags. Both host
CPU pools were held at high priority; the controller used CPUs 0-7.

Eight boundary tests pass locally and on HP, zero skips. They check exact timed
task preservation, fixed transport/environment policy, changed-template and
unknown-profile refusals, independently validated primary/delay/raw series,
altered count/rate/value/trailing-data refusals, achieved rate and scheduler-only
clamping disclosure.

Five real kernel-loopback pairs exercise every allowed rate and both upstream
RDTSCP and monotonic clocks, with 64 measured calls and three warmups per pair.
Both original-peer and new-sender processes return zero. Independent cold audits
validate all required FIX fields/groups/envelopes/checksums and contiguous
numeric owners: 320 measured calls, 15 warmups and 670 persisted endpoint order
records. Raw primary/delay output checks pass. Four native CLI controls refuse
unknown rate, zero measured count, zero warmup and missing configuration before
creating runtime output. No skips or Onload/physical timing promotion.

The separate sender SHA256 is
`bbaeb3ecadb3fca55dd8392899e3eb5758a7e582b62edeef21705b927e6f7207`.
Original TX/framework TX/peer copies retain their previous hashes exactly:
`8003c3734c257c5e76f9a226f542c42d544ca52c83ef1401bec78ff4f09fabd5`,
`ac8f28091bf835ee626ef2bb851ec84b3856e2acc21eaaf6e1089c6077442a5c`,
`9f7a2379b99da6c7df7216f276bde074c30b72de0d27fcae902cb278677f1cf4`.

## Persistent installer and required next step

Installer inputs live under
`~/.cache/libhft/llfix-reference-hp-load-v1-7fc38f148858/` on HP. The frozen
60-file runnable controller/header capsule also lives there, with independently
verified bytes/modes. It does not depend on a disposable build directory.
Runtime output remains under the owning session build root,
`~/build/codex-llfix-reference/libhft/onload-load-generation1`.

`~/install-llfix-load-controls.sh` checks the reviewed installer hash, then uses
sudo to install its sealed, fixed-destination payload and four launchers. It
refuses changed baseline/source inputs and existing versioned destinations.
It changes no old payload, sudoers entry, global sysctl, namespace topology or
SDK. Bash syntax verification passes. Each execution creates a separate retained
install log. Installer SHA256:
`cca167b97b1f3a728814bc53bafe3f32563a6fd0dec93bf0870445ecec41a1ff`.
Wrapper SHA256:
`d501be4f862965d22df09983e32fecc4dd0eb27814c1a59395ef28253975d300`.

The automatic `sudo -n` attempt was refused with `a password is required`;
the new payload was absent at that checkpoint. HP's installed password-free
rules permit existing protected namespace launchers, not arbitrary new root
installation. The manual step is `bash ~/install-llfix-load-controls.sh` on HP.
After exact installed-input validation, queue high-priority physical controls
under both CPU pools, then cold audits under shared/high. Buffer and rate
controls run in forward/reverse order with 1000000 measured calls and 1000
warmups, recording TCP pressure/actual buffers and physical port deltas.

## Preserved refusal and retention

The first cache staging validator ran without disabling Python bytecode writes.
It created 12 generated `.pyc` files beside the captured controllers/frozen
support; the exact source-tree check correctly refused the extra files. Its
failure and every generated bytecode file are retained. A separate continuation
checks each generated file's exact hash/recorded modification timestamp, retains it, and
removes only those matching generated copies. All sealed source bytes remain
unchanged. The continuation disables bytecode writes and validates identical
source/native/header maps, with only fixed installer source-path/hash fields
adapted for the persistent cache. The original failure remains failed.

Both HP and BEELINK2 independently stream and verify all 186 sealed files,
their sizes, modes and SHA256 values. Their passing replica receipts are equal.
The full archive retains 7386601586 bytes, compressed to 8589130 bytes:
`~/archive/libhft/codex-llfix-reference-20261007/hp-load-controls-preparation1/hp-load-preparation1.tar.gz`.

Archive SHA256:
`616cc43470e92bf5850c2be5e6ad8c2756e811cfc3d608f24058549640cf5af7`.
Seal SHA256:
`bb15cf8fd32700eea8c8b34002bd11dfbc5697db1e944370debe416138fc172d`.
Verifier SHA256:
`b9e23eac234d3095e1815568aad415bb2b245a721f3ccd4dc5349660fe070caf`.

The [Git selection](evidence/llfix-hp-load-preparation-20261007/selection-manifest.json)
retains exact small metadata/raw series, configuration/logs, installer and
source/native hash bindings. Full binaries, journals, source capsules and
generated bytecode remain in the verified archive. The replica receipts and
persistent-source continuation are explicit companions outside the original
seal. No unsuccessful receipt or previous ranking is rewritten.

After normal rebase over concurrent Java/Rust/recovery work, integrated
`867505b6d6fc625594f82199bbb0c9aa8c78c675` preserves all 60 source input files
and 55 selected sealed files byte for byte and mode for mode. All eight boundary
checks pass again with zero skips. The separately retained
[integration receipt](evidence/llfix-hp-load-preparation-20261007/integration1.json)
does not rebuild or regrade the frozen native generation.