VoxelBench 2.2.0

The disk test finishes on slow storage, and long tests say where they are

VoxelBench 2.2.0 fixes a disk test that could end with no measurement at all on slow or shared storage, and makes long tests report their progress — in the console, on your voxelbench.com auto-bench dashboard, and in the report of a test that did not finish. If the disk test of your /bench start failed with "hard ceiling" on your host, this release is for you.

The disk test on slow storage

Up to 2.1.0 the disk test ran a fixed amount of work: in /bench start, three passes over a 1 GiB file, each with 500,000 random 4K writes and 500,000 random 4K reads. On storage that answers in about 2 ms per write — shared storage under load, which is common on hosting plans — one random phase alone needed about 17 minutes. The test then reached its 15-minute limit and threw away everything it had measured: the report said hard_ceiling and nothing else.

Each phase now stops after 40 s (sequential) or 60 s (random) and gives the rate of what it did in that time. The phases of three passes add up to 10 minutes at most, well under the limit, so slow storage gets a measurement instead of a failure.
On storage that keeps up, nothing changes: the phases finish their planned amount long before their limit (a few seconds each on NVMe).
The report says when a phase reached its limit (timeCappedPhases), and voxelbench.com shows it on the test: the rates of such a phase cover the time it ran, not the amount it planned.
The test really stops when it reaches its time limit or on /bench stop. It used to keep writing in the background during the following tests. Its test file is deleted.
It checks the free space first. Without room for its file plus 256 MiB, it is skipped (prerequisite_missing) instead of filling the server's disk.

Long tests say where they are

disk (four stages per pass), memory (seven per pass) and multiCore (its tasks) now report their stages. What the console shows follows logging.test-verbosity:

NORMAL (default): for a stage lasting 30 s or more, its progress every 30 s, then its result — for example random 4K write: 847495/2000000 ops (42%), 37 s in stage, 22905 ops/s on average. On a fast server, nothing more than before.
VERBOSE: every stage, and a status line every 10 s; for the disk test, with the bytes the server really reads and writes and the I/O pressure of the container and of the host.
DEBUG: before the disk test, the storage as the server sees it (mount, device, I/O limits, memory) and its latency on a few operations; the stacks of the test's threads when a stage stops progressing for 20 s, and when a test reaches its time limit. Set it, run the test, and you have what is needed to tell a slow host from a stuck test.

/bench reload applies the level.

A test that does not finish says where it stopped. Its console line names the stage and how far it got — "hard ceiling of 900s reached … during pass 1/3

random 4K write (136331/500000 ops (27%)), 284 s in that stage" — and its report carries the same, which voxelbench.com shows as "Stopped during".

Auto-bench

The auto-bench dashboard on voxelbench.com now shows the stage of a long test while it runs ("pass 1/3 · random 4K write: 136,331 / 500,000 operations (27 %)"). Standard runs report the progress of their tests too: the dashboard used to stay on "test 1/12: disk" for as long as the disk test lasted. At most one progress line a minute is sent, so the dashboard can be a stage behind.

Smaller fixes

The test detail shown at VERBOSE printed an internal class name (vxb.zd@58590048) instead of each measured value.
Two disk test console messages were in French.

Upgrade

Drop the new jar in plugins/ and restart. No config or data migration, and no new setting: the stages use logging.test-verbosity. The description of that setting in config.yml is updated for new installs only; an existing file keeps its old comment, and the levels behave as described above.