# Philadelphia-fast session observations and physical harness

The [retained bundle](evidence/philadelphia-session-instrumented-20261002/SHA256SUMS)
contains original manifests, matching adapter and controller sources, full raw
samples, first-cycle sent/received frames, canonical audits and process logs.
All original manifest hashes were checked before retention. These are two-process
localhost diagnostics on HP, using `isol` while shared conformance work ran.
**No new physical Stage 5 result or speed claim is made.**

## Production session and observations

`PHDacSession` uses the pinned public Maven artifact
`com.paritytrading.philadelphia:philadelphia-core:2.0.0`, SHA-256
`396136037b0f41e635e3aea233c3f31f4a388318b445f4afe1609b9a6d28a7b7`.
This identifies the tested binary artifact; it is not a claim that it was rebuilt
from the roster's separate Stage 0 Git pin. The unchanged `FIXConnectionFast`
facade runs on one foreground owner per process, with TCP_NODELAY and fixed
`-Xms128m -Xmx128m`. Production framing, checksums and session processing remain
enabled. Philadelphia has no dictionary validation or message store in this arm.
Every application cycle decodes and checks all canonical fields and book entries;
standard snapshots have ten bids and ten asks. Mixed orders use the parsed best ask.

The public production `GatheringByteChannel` hook observes fully prepared
header/body/checksum buffers. Tick-to-trade starts immediately before the first
kernel write of that prepared W and ends after the server extracts its reactive D.
The server paces W autonomously; the measured flow has no setup V, trigger order
or execution-report leg. Partial writes retain the first-send timestamp.

A bounded transport observer handles fragmented and coalesced TCP reads and
counts complete incoming admin frames after production receive processing,
in application dispatch order. Outgoing admin observations use the prepared-send
hook. Both roles emit measured-window admin counts and ResendRequests, including
explicit zeroes. The sample owner retains exactly one positive primary latency
and one scheduler-delay value per measured cycle, as UInt64 nanoseconds.

A separate diagnostic injects a TestRequest midway through each measured flow.
The production peer returns a Heartbeat; both roles observe incoming and outgoing
admin messages on all four flows, with zero ResendRequests. Injected probes remain
diagnostic and the root launcher clears their environment variable. Normal
short measurements observed zero admin messages, rather than assuming zero.

The later adapter skips reformatting the production millisecond timestamp when
the millisecond has not changed. Heartbeat processing still runs on every poll.
The before/after sources and both medium bundles are retained independently.

## Retained local results

Five warmups and 20 samples at 100/s complete the protocol, canonical wire and
raw-sample gates on all four flows, but the cold order-entry and tick-to-trade
runs miss the rate gate. A later 1,000-warmup tiny bundle also has rate failures.
These failed rate gates remain visible; they are not successful timing results.

The final medium diagnostic uses 50,000 paced excluded warmups, 10,000 samples
per fresh process pair, three pairs per flow and an offered 10,000 cycles/s.
Every process completes bilateral logon/logout and exact full-cycle application
counts. Each flow retains 30,000 primary and 30,000 scheduler-delay samples.
The local gate permits 5% rate error; physical report promotion additionally
requires at least 98% in every run.

| Flow | Achieved cycles/s, three runs | Mean run p99, us | Stability | Local gate |
|---|---|---:|---|---|
| `nos_er` | 9959.239, 9644.049, 9889.983 | 20.906 | FAIL | fail |
| `md` | 9001.658, 9084.094, 9099.775 | 27.375 | FAIL | fail |
| `md_nos_er` | 9964.639, 9965.240, 9964.815 | 44.653 | PASS | pass |
| `tick_to_trade` | 9963.693, 9604.580, 9964.287 | 18.231 | PASS | pass |

The separate GC/safepoint logging diagnostic retains its original logs and raw
samples. It confirms pauses occur and retains long scheduler-delay outliers;
it does not establish a single cause for the market-data rate shortfall. It
uses logging and remains diagnostic. Concurrent shared host activity and fresh
JVM process variation have not been ruled out.

## Physical integration

`run_dac_philadelphia_session.py` reuses the physical counters and raw/wire/rate/
stability/admin grader through an explicit `SessionCampaign`. Rust keeps its
existing payload, launcher, profiles and schema. Philadelphia has a separate
schema, five-file immutable payload and fixed root namespace launcher. The
controller checks every root-owned installed byte against the admitted hashes
and retains the entry point, shared controller, grader and build provenance.

The medium physical profile retains the same 50,000 excluded paced warmups,
10,000 samples and three process pairs. The tiny physical profile has 1,000
warmups and 20 samples at 100/s. Report promotion requires the selected physical
DAC rig, positive TX deltas on both ports, `isol-no-shared`, all canonical flows,
complete raw observations, admin/resend proof, prepared-wire tick boundary,
98% achieved rate and PASS stability. Local or injected diagnostics cannot pass
these report gates.

The SHA-pinned payload is staged under
`~/.cache/libhft/fullbench-philadelphia-session-instrumented-20261002` on HP and SCAN.
`install-dac-philadelphia-session-stage5.sh` checks its five files and fixed launcher,
refuses unknown or user-writable installed inputs, and installs atomically.
It preserves the older fullbench Java jars and their launchers. Root installation
and physical execution remain pending. HP jobs use high-priority host slots.