Phase M1: Client (1, 8, 64 workers)

Three client arms over a private VPC against a 3-node double-redundancy ssd-2 FoundationDB 7.3.77 cluster (17 server processes, 9 storage servers), in three closed-loop concurrency phases: M1w1 (1 worker), M1w8 (8 workers) and M1w64 (64 workers). This is phase M1 of fdbmn-20261020.

Design and scope

• After M2, data distribution was re-enabled and the cluster held zero data movement for 121.474 s, with stable roles and CPU pins, before M1w1.
• Phases ran in the preregistered order M1w1 → M1w64 → M1w8. M1w32 was dropped for budget before measurement and was never replaced with capacity data.
• Each workload runs six blocks, one for each order of the three arms: 18 fresh processes per workload. Transaction counts are totals across workers:
  • M1w1: 3,000 measured + 200 warmup per run (18,000 measured per arm and workload).
  • M1w8: 12,000 + 800 per run (72,000 per arm and workload).
  • M1w64: 32,000 + 1,600 per run (192,000 per arm and workload).
• Workload order at every worker count: grv, get100, get1000, range100, set100, batchset50, batchset50x1000. Per-process 180 s and per-workload 900 s caps.
• Claim scope: each ratio is a within-worker-level paired contrast. Worker levels ran in a fixed sequence with different transaction counts, so they are not compared with each other.
• Metric scopes: lifecycle CPU (E−A) is process user+system CPU from after binary identity hashing through measurement, finalizer drain, database close and native network stop, divided by measured transactions. Go bytes and mallocs per transaction count the Go heap only and exclude the native libfdb_c heap, so CGo’s small Go counts do not describe its memory use.
• Harness: all three arms use the identical amended harness archive (d94b4c613 plus the #948 lifecycle-drain fix and matching validator). Workloads, timing windows, pacing, CPU accounting and estimators are those of the frozen harness.
• Polling change: from M1w8 on, the controller reused one SSH connection and polled every 60 s instead of 10 s. M1w64 ran entirely under the original controller.

Exclusions

• M1w1: 4 of 7 workloads clean. Before set100’s first arm, the client pre-arm gate measured 17.17% busy on one CPU, above the 15% limit (aggregate 4.01%, no steal). The arm was not launched, and the preregistered stop-on-failure policy ended the phase before batchset50 and batchset50x1000. All three write comparisons are N/A.
• M1w64: 5 of 7 clean. After the first master batchset50 arm, the server’s transaction-log queue was 426,278,385 bytes, above the 100 MB gate. That arm completed 32,000 of 32,000 commits with no errors or retries and passed validation; the whole comparison is still excluded. batchset50x1000 was not reached.
• M1w8: 5 of 7 clean. The log queue was 118,497,454 bytes after the first master batchset50 arm. batchset50x1000 was not reached.
• No case was rerun or partially salvaged.

Results

Geometric mean of six paired block ratios, with nominal 95% block-bootstrap intervals (20,000 resamples, preregistered seed 492817). Below 1 means the numerator has lower latency, CPU or allocation.

On Linux, master’s pure-Go client coalesces outgoing requests before a write batch, using the same 10 µs minimum and 20 µs maximum delay settings as libfdb_c 7.3.77. The delay depends on time since the last write and is jittered. fdb.WithCoalesceDelay(minDelay, maxDelay time.Duration) changes those settings.

M1w1 (1 worker, 18,000 tx/arm per workload — 4/7 clean)

M1w1: master / old Go

M1w1: master / CGo

M1w1: old Go / CGo

M1w8 (8 workers, 72,000 tx/arm per workload — 5/7 clean)

M1w8: master / old Go

M1w8: master / CGo

The set100 p99 upper bound rounds to 1.000; unrounded it is 0.99954.

M1w8: old Go / CGo

M1w64 (64 workers, 192,000 tx/arm per workload — 5/7 clean)

M1w64: master / old Go

Range100 at 64 workers is unstable: its master/old intervals are wide in every metric. Per-order, half-split, moving-block and leave-one-block-out diagnostics for every estimate are in analysis/M1-comparisons.csv.

M1w64: master / CGo

M1w64: old Go / CGo

p99.9 is in the detailed outputs but is not reported here: six blocks are too few for it.

Absolute values

Medians of six run-level statistics per arm. These are not quantiles of pooled transactions.

Throughput (post-hoc, exploratory)

Post-hoc and exploratory: throughput was not preregistered. The rates and intervals below are derived afterwards from the retained raw data of the same eligible cases. They do not change any estimate, exclusion or result above.

• Throughput: completed operations divided by the measured wall window, in operations per second. One operation is one workload transaction. The window excludes setup, warmup, validation and shutdown.
• Busy cores: client process user+system CPU during the measured window divided by its wall time (1.0 = one core busy), including Go and native threads but not the FDB servers. This is not the lifecycle E−A CPU reported above.
• Estimates: absolute ops/s and busy cores are medians of six processes per arm. Ratios are geometric means of six within-block throughput ratios, with the same bootstrap as above (20,000 resamples, seed 492817). Above 1 means the numerator completes more operations per second. Ratios are not quotients of the displayed medians.
• Closed loop: each phase runs a fixed number of workers, so the measured rate is 0.973–1.000 (median 0.998) of workers divided by mean latency. The rates describe these operating points, not peak or saturated throughput.

M1w1: throughput

M1w8: throughput

M1w64: throughput

Range100 at 64 workers has a wide, unstable interval here as well. Process, absolute, paired and omission records, all marked post-hoc, are in analysis/M1-throughput.csv; formulas and scopes are in analysis/throughput-method.json.

Comparison with the 2026-10-14 campaign

Old Go is the revision the 2026-10-14 campaign measured as its final pure-Go tree. Its ratio to each campaign’s own CGo arm shows how much the two cohorts differ before any code change is considered: fresh hosts, a three-arm schedule, the harness amendment and different times. Blocks are never pooled across campaigns, and no cross-campaign interval or ratio of ratios is computed.

Old Go / CGo in both campaigns

• The same revision’s CPU ratio to CGo is similar in both cohorts. For set100, old Go/CGo E−A CPU was 2.142 (8 workers) and 1.981 (64 workers) on 2026-10-14, and is 2.075 and 2.132 now. Master/CGo is 1.148 and 1.249. That describes a smaller Go-versus-CGo CPU gap; the reported comparison remains the directly paired master/old contrast.
• Latency ratios to CGo vary more between cohorts, notably set100 p50 at 64 workers (0.884 then, 0.696 now). Cross-campaign differences in absolute latency are not attributed to code.