raphael
60fa164626
02 — The cast of characters: equipment, EAP, MES, fab planner, AMHS, operator. Who initiates which conversation, why the equipment is the passive side of HSMS by convention, how the AMHS handshake is out-of-band relative to SECS. Cross-references the relevant namespace and test files for each actor. 03 — Vocabulary + a wafer's journey: follows one 300 mm wafer end-to-end through a fab and labels every SECS message and acronym that fires. Introduces SVID / DVID / ECID / CEID / RPTID / ALID / PPID / MDLN / SOFTREV / HCACK / ALCD / OFLACK / CAACK / SMACK / etc. in context rather than as a list. Includes one-screen reference tables for the remaining acknowledge codes, T-timers in all four contexts (HSMS / SECS-I / E84 / E30 communication state), and a stream-by-stream summary. Part 1 (Foundations) of the guided tour is now complete — a reader who reads chapters 01–03 can describe the protocol stack, identify the actors, and recognise every acronym they'll meet in Part 2. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
3.0 KiB
Performance baseline
Numbers from build/secs_bench --requests 20000 --concurrency 16 on
Docker / Ubuntu 24.04 inside Docker Desktop on macOS (M-series), single
io_context thread. Treat as rough envelope for capacity planning,
not lab-grade benchmarks; re-run on your target hardware before
sizing pods or VMs.
Round-trip throughput / latency
| Scenario | Ops | Elapsed | Ops/sec | p50 µs | p95 µs | p99 µs |
|---|---|---|---|---|---|---|
| S1F1/F2 (header-only) | 20000 | 0.14 | ~140000 | 74 | 103 | 161 |
| S1F3/F4 (32 SVIDs) | 20000 | 0.25 | ~79000 | 165 | 186 | 260 |
| S6F11 push (W=0) | 20000 | 0.03 | ~572000 | n/a | n/a | n/a |
Read the table this way. A real fab tool needs to handle tens to a few hundred S6F11 events/second sustained. We're three orders of magnitude above that on the push path, two orders above on synchronous round-trips. Throughput is not the bottleneck; latency tail under contention is.
Memory footprint
A ProcessJob + ControlJob pair (no persistence enabled) is around
~450 bytes of heap (1000 pairs ≈ 0.45 MiB, measured on a fresh
process). With persistence enabled add ~200 bytes of in-memory journal
path tracking per record.
| Active entity | Approx bytes / instance |
|---|---|
| PJ + CJ pair | ~450 |
| Carrier (no slots) | ~80 |
| Carrier slot | ~24 |
| Substrate | ~120 |
| Spool entry | ~40 + encoded body size |
A busy fab tool tracking 50 carriers × 25 slots, 200 substrates, 20 active PJ+CJ pairs comes in well under 1 MiB of model state. RSS will be dominated by the binary itself + asio's buffers (~10-20 MiB), not the model.
How to re-run
docker compose run --rm builder /app/build/secs_bench \
--requests 50000 \
--concurrency 32 \
--svid-count 32 \
--store-pairs 10000
Output is markdown — pipe to a file and commit it to your CI so regressions show up as diffs.
What this does NOT measure
- Real network. Loopback TCP has no MTU fragmentation, no retransmits, no jitter. Production HSMS over a fab control LAN will see higher tail latency.
- Persistence write amplification. The bench runs with persistence disabled. Each store mutation with persistence enabled is one atomic-rename to disk; on rotational media that limits you to a few hundred mutations/sec. SSD-backed deployments are fine.
- Concurrent S6F11 enable filtering. Real CEID emission gates on the host's enable/disable list — this bench fires raw S6F11s.
- Multi-session HSMS-GS dispatch overhead — single-session only.
- TLS-tunneled sockets (via stunnel/sidecar) — these add ~50 µs per round-trip on modern hardware.