docs(bench): recontextualise CubeSandbox row + small-N replay numbers#42
Merged
Conversation
… small-N replay After filing TencentCloud/CubeSandbox#235, the Cube maintainer confirmed two things that recontextualise the 20.3 s / 77-of-100 N=100 number we'd published: 1. The reflink-copy race lives on a slow code path the original template inadvertently selected — `--writable-layer-size 2Gi` doesn't match the default `pool_default_format_size_list = ["1Gi"]`, so every sandbox went through live `mkfs.ext4 + reflink-copy` instead of the pool fast path. The fast path (writable_layer_size matches pool) doesn't run the racy code. 2. Cube's published "<60 ms single-instance / P95 90 ms @ N=50 / <200 ms @ N=100" numbers are measured on a 96 vCPU server. Our 20 vCPU host is outside their tested matrix. Neither of those changes the fact that the 20.3 s figure is what we measured. They do change how the row should be interpreted, so: - README.md: both footnotes ¹ rewritten to lead with "slow-path measurement on a host outside CubeSandbox's documented testing matrix". The 20.3 s number stays in the table. The footnote now explicitly says we did not re-test the fast-path configuration. - bench/CUBESANDBOX.md: two new sections. "Upstream response (2026-05-14)" — the two clarifications from Tencent verbatim, plus a note that they accepted the first two fixes from our issue (configurable cmdTimeout, richer error diagnostics) and are reviewing the third. "Small-N replay on the same (slow-path) configuration" — we re-ran with the same 2 GiB template at N=1, N=5, N=10 to fit the 30 GiB host RAM budget. 100% success at every size; cold start ~924 ms, per-sandbox cost shrinks to 257 ms at N=10 (consistent with the 20.3 s / 100 = 203 ms-per-sandbox at N=100). Confirms the race is a slow-path-at-high-N phenomenon, not a general spawn-time issue. - bench/cube-replay.sh: the script that produced the small-N numbers, parking it next to the rest of bench/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to TencentCloud/CubeSandbox#235. The Cube maintainer responded with two clarifications that change how the 20.3 s / 77-of-100 N=100 number should be interpreted (without changing the measurement itself).
What the Cube team said
Cube also accepted the first two improvements from our issue (configurable `cmdTimeout`, richer diagnostic info on `newExt4RawByReflinkCopy` failures) and is reviewing the third (drop per-clone `e2fsck`).
Doc changes
Small-N replay results
Same 2 GiB template (slow path), this dev box (20 vCPU / 30 GiB):
100 % success at every size measured — the race is specifically a slow-path-at-high-N phenomenon. The 20.3 s / 100 = 203 ms-per-sandbox figure at N=100 is consistent with the per-sandbox cost shrinking with concurrency.
Test plan
🤖 Generated with Claude Code