Smooth Server 0.2 — NeoForge CPU-only alpha

Smooth Server brings together a small selection of mods aimed at improving server tick processing, chunk handling and memory use. This dedicated-server edition targets Minecraft 26.1.2 and NeoForge 26.1.2.116. Players do not need this pack to join.

Alpha release: this CPU-only edition replaces Moonrise with C2ME NeoForge. It does not include C2ME OpenCL or require GPU access. C2ME remains experimental; back up existing worlds before changing versions.

Included mods

Mod	Exact version
spark	1.10.187-neoforge
No Chat Reports	NeoForge-26.1-v2.19.0
Lithium	mc26.1.2-0.24.7-neoforge
FerriteCore	9.0.0-neoforge
Chunky	1.5.4
C2ME NeoForge	0.4.0-alpha.0.100+26.1.2

Exact differences from 0.1

Reference: published 0.1 release gypoASol. Removed Moonrise 1.0.1+2cd8eef; added C2ME NeoForge 0.4.0-alpha.0.100+26.1.2. Lithium, FerriteCore, Chunky, spark and No Chat Reports retain the exact published 0.1 binaries. ScalableLux, Fast Noise, SLO and ModernFix are excluded; their incremental value was not established in this CPU-only protocol. Moonrise and C2ME are never combined.

Direct concurrent/shared-host measurements

Both versions ran simultaneously with synchronized comparable phases. Each server received two logical processors on two distinct physical cores, a 2 GiB heap and a 4 GiB Java-process commit cap. The second matched pair swapped CPU placements. The combined server allocation was four physical cores, 4 GiB of heap and an 8 GiB process-commit ceiling. Two other physical cores were shared by measurement/client helpers; each client driver had a 512 MiB process cap. OS/Python/unrelated applications were not memory-capped. This is a partitioned shared host, not CPU oversubscription.

Both worlds, logs and libraries on C:; separate world copies on the same volume; warm uncontrolled OS cache; no storage isolation. Host CPU and disk counters include unrelated processes. The host inventory, masks, phase overlap and raw samples are preserved.

Measurement	Published 0.1	CPU-only 0.2
Generation chunks/s, mean of two concurrent runs	24.23	30.23
synthetic-0-players, mean MSPT	2.56	3.15
synthetic-0-players, mean of per-run p99 MSPT	14.78	18.81
synthetic-1-player, mean MSPT	4.30	4.96
synthetic-1-player, mean of per-run p99 MSPT	34.85	33.19
synthetic-2-players, mean MSPT	4.01	4.72
synthetic-2-players, mean of per-run p99 MSPT	24.34	28.51
pathfinding-tracking-collisions-2-players, mean MSPT	2.29	2.92
pathfinding-tracking-collisions-2-players, mean of per-run p99 MSPT	17.62	21.03
hoppers-furnaces-2-players, mean MSPT	1.06	1.17
hoppers-furnaces-2-players, mean of per-run p99 MSPT	3.95	4.92
clocked-redstone-2-players, mean MSPT	2.52	3.23
clocked-redstone-2-players, mean of per-run p99 MSPT	29.69	34.83
pregenerated-2-players, mean MSPT	5.27	5.61
pregenerated-2-players, mean of per-run p99 MSPT	52.11	44.01
fresh-terrain-2-players, mean MSPT	4.12	4.57
fresh-terrain-2-players, mean of per-run p99 MSPT	47.21	33.37
generated-first-pass, mean decoded latency ms	1381.25	705.88
generated-repeat-pass, mean decoded latency ms	224.25	124.75
fresh-generation, mean decoded latency ms	3414.62	1902.12

Two matched workload pairs and two decoded-loading pairs were measured; one simultaneous twenty-minute sustained run was performed per version. These reduced repetitions do not establish statistical significance or intermittent-failure rates. Lower MSPT/latency is better; higher generation throughput is better. Loading uses full decoded terrain with a bedrock sentinel. Inter-target synchronization waits are excluded from individual request/task timings. Earlier isolated and hardware-accelerated measurements are not reused.

Simultaneous sustained run

Metric	0.1	0.2
seconds	1200.03	1200.03
tps	19.69	20.00
mean_mspt	4.70	5.21
p99_mspt	25.42	30.42
rss_peak_mib	1900.82	1579.99

Each version completed ten synchronized two-minute cycles, fresh exploration, nine reconnects of both clients, repeated saves, furnace-output and item-conservation checks, clean shutdown, saved-region allocation/compression/NBT/coordinate scans and live save/restart checks.

CPU-only verification

Both JVMs ran with a test-only native-library guard that denies OpenCL/CUDA and related graphics library loads. A positive control confirmed that both System.loadLibrary and the foreign-function native lookup API were blocked. The measured servers made no forbidden native-load requests and loaded no OpenCL/CUDA runtime modules. The OpenCL addon is absent, so this result does not rely on its silent fallback. The guard is measurement instrumentation and is not shipped in the pack.

Limits and behavior

Java 25 is required. View/simulation distances were 6 and both versions used the same calibrated G1 flags. Loopback scripted clients do not establish WAN/authentication or rendering performance. No Chat Reports changes chat reporting. C2ME remains alpha; the earlier scripted-client reconnect failure observed on published 0.1 remains unresolved. Exact vanilla redstone/farm, biome/structure parity, overnight memory retention, larger player counts and other hosts were not established. One-core scaling was deliberately skipped. No previous qualification results are pooled into these concurrent/shared-host figures.

Failures and deadline

The controller preserves unsuccessful attempts and refuses to package a passing release if any required pair or check is unfinished. This new experiment ends at midnight Europe/Paris, with a ten-minute graceful-shutdown/report reserve. Raw attempt status, host conditions and completion timestamps accompany the local comparison.

Excluded harness revisions are preserved separately: r1 failed before Minecraft startup because of diagnostic JVM flag ordering; r3 hit a permission error at initial warmup whose exact cause remains unproved; r4 was stopped to correct the deadline anchor. Revision r5 passed the workload stages, but save/restart overwrote its tick/JFR/GC traces and prevented independent report verification. The r6 attempt then failed when published 0.1 did not complete a scripted-client reconnect within 60 seconds. Five subsequent diagnostic cycles per version passed without reproducing the failure; the root cause remains unproved. This new r8 window repeats the complete scope with timestamped protocol-state and packet-name logging throughout every client session, including reconnects. Client timeout and all workload acceptance criteria remain unchanged. No performance observations from those earlier revisions are included here.

Installation

Use Java 25 and a dedicated-server installer supporting NeoForge .mrpack files. Read the Minecraft EULA and review the small-server settings before starting. Do not add Moonrise alongside C2ME. Chunky pregeneration and spark profiling run only when requested. All credit for the included mods belongs to their authors.

Measured tradeoff: generation throughput increased 24.8%. Decoded loading latency decreased 48.9% on first pass, 44.4% on repeat pass and 44.3% during fresh generation. Sustained mean MSPT increased 11.0%, p99 MSPT increased 19.7%, and sampled peak RSS decreased 16.9%. All eight full-workload phase means were higher with 0.2. This is a chunk-handling/memory tradeoff with tick-time regressions, not a universal performance improvement.

Review findings from the new window

All ten server trials completed, including both workload pairs, both decoded-loading pairs and the simultaneous sustained pair. They finished at 23:01:20 Europe/Paris on 26 October, before the 23:50 stop-work reserve and midnight deadline. The independent review recalculated every reported tick mean, nearest-rank p99, loading mean and sustained statistic from the preserved measurement evidence, and checked all 30 tick/JFR/GC hashes. Largest timed-phase start skew: 73 ms; minimum phase overlap: 99.913%; largest decoded-request start skew: 5 ms.

Detailed connection logging covered 96 successful client connections across 50 ready cycles, including restart sessions. No 60-second login timeout recurred in this window. Nine two-client sustained reconnects passed per version. This does not establish that the earlier intermittent problem is fixed: it did not reproduce, its cause remains unknown, and no timeout or readiness check was relaxed. Detailed logging overhead was applied to both versions; its magnitude was not separately measured.

The host reported 18 physical cores, 26 logical processors and approximately 31.7 GiB usable RAM, running Windows 10 on shared C: NTFS storage. Server CPU masks were 5 and 80, reversed for pair 2; helpers shared mask 1280. Only the documented four physical cores and aggregate 8 GiB Java commit cap were assigned to the two servers. Other host cores/memory and background applications remained available and uncontrolled. These results describe this partitioned host, not a saturated oversubscribed host.

The release archive contains six Modrinth downloads and server configuration overrides. It contains no benchmark recorder, test guard, Java agent, test world, connection log or credential. Production defaults restore online-mode=true, normal port 25565, world name world and an unaccepted EULA. Measurements used loopback scripted clients and test instrumentation. The final archive was inspected and its hashes/configs checked; a separate fresh installer/WAN authentication smoke test was not performed.

The superseded GPU experiment and its three startup failures caused by a harness newline-copy bug also remain excluded. No GPU or earlier isolated measurement is used. Revision r7 was proposed but not executed after automatic approval review rejected a further undiagnosed retry; it contributes no measurements. Only namespace cpu-shared-r8 supplies the tables above.