Redstone gets blamed for lag more often than any other mechanic in Minecraft, and the blame usually lands in the wrong place. This guide exists to help server owners and technical players stop guessing. It comes from a set of controlled experiments we ran on Paper 26.2 with an empty sky deck, no plugins, no players, and every source of random work switched off, so redstone was the only variable left.

The short version: the cost is not the number of redstone components you place. It is the number of block state changes and scheduled ticks that land on the main thread inside the same 50 millisecond window. We measured 5,000 observer clocks adding 5.3 ms per tick and 5,000 chained repeaters adding essentially nothing, and that gap explains most redstone lag arguments you see on forums.

The Tick Budget in Plain English

Minecraft runs at 20 ticks per second, which gives every tick a 50 ms budget of wall clock time. If the server finishes its work in 4.3 ms, it idles for the rest. If it needs 9.6 ms, it still hits 20 TPS because there is headroom. Once the average crosses 50 ms, ticks start being skipped and TPS falls below 20. MSPT (milliseconds per tick) is the number to watch, because TPS hides problems until they are severe. Our MSPT and tick rate performance guide covers the arithmetic in detail.

What “tick sync” actually means

Tick sync is shorthand for a simple fact: everything that mutates world state runs in a fixed order on one thread. Scheduled block ticks, neighbor updates, entity ticks, block entity ticks, and chunk ticking are all serialized on the main server thread, once per tick. Async chunk generation on Paper, Netty handling packets, and plugin async tasks move work off that thread, but none of them move redstone work off it. A circuit that fires every tick has to finish inside the tick.

That is why adding cores rarely helps a redstone-heavy base. The Paper configuration reference has dozens of knobs, and not one of them parallelizes block updates.

How Redstone Becomes MSPT

Two things cost time, and they are not the same thing. Scheduled ticks are queued with a delay: a repeater or observer that fires waits a set number of ticks before its next action, and the queue is drained every tick. Neighbor updates happen immediately, in the same tick, when a block changes state. Every update makes the game check surrounding blocks, and those checks can schedule more ticks and emit more updates. Breadth matters more than the size of the build.

Why the same circuit behaves differently in two places

Update order is the reason. The engine walks block positions in a fixed sequence, and circuits that depend on which neighbor updates first will behave one way at spawn and another 30,000 blocks out. Chunk boundaries, the direction a wire runs, and even the order two pistons are placed can flip a race. That is not a bug to report; it is a property of the redstone update mechanics you are building against. Design circuits that tolerate reordering instead of ones that need a specific order.

Cost per component is not equal either. Observers and redstone dust are update generators: dust recomputes power and notifies neighbors, observers schedule a pulse and emit updates. Repeaters are cheap when idle because their scheduled tick is far in the future. Pistons are the most expensive single block, since a push changes many block states and can spawn moving-block entities.

The Test That Surprised Us

We built a flat deck in the sky with nothing on it, disabled mob spawning, random ticks, and the daylight cycle, then recorded MSPT until the numbers stopped drifting. Then we added one circuit type, warmed up again, and sampled for two minutes. Every run used identical gamerules and a fresh world so chunk state could not leak between tests.

/gamerule randomTickSpeed 0
/gamerule doMobSpawning false
/gamerule doDaylightCycle false
/difficulty peaceful

# baseline sanity check
/tick query

# collect a real sample, not a single reading
/spark profiler start --timeout 120
/spark profiler stop

# repeat with the circuit placed, then subtract the baseline

1. Run the empty deck for 5 minutes so JIT and chunk loading settle.
2. Sample 120 seconds twice and keep the median and the P99, not the average alone.
3. Place exactly one circuit type and warm up again.
4. Sample the same way, then subtract the empty-deck median.
5. Change one variable per run, or the number means nothing.

For reading the output, our beginner’s guide to spark reports walks through the flame graph, and the spark documentation covers sampling flags.

What 5,000 Observers Actually Cost

Hardware was a 16 vCPU host with -Xms2G -Xmx4G and G1GC. Observer pairs were self-clocking, each with a 2-tick feedback loop, so every pair changed state constantly. The repeater test was a delay line: 5,000 repeaters in rows of 250, delay 1, fed by a redstone block toggled every 20 ticks.

Scenario	Median MSPT	Delta	What it means
Empty deck	4.3 ms	baseline	Server had lots of headroom
1,000 observer pairs	5.4 ms	+1.1 ms	Linear so far; still comfortable
5,000 observer pairs	9.6 ms	+5.3 ms	P99 hit 20.6 ms; TPS stayed 20
5,000 chained repeaters	4.2-4.5 ms	~0 ms	Only the wavefront changed state

The repeater result is the most useful lesson in the whole experiment, not a failed test. Five thousand blocks were capable of ticking, but roughly 20 of them changed state on any given tick, because the pulse was still traveling down the line. A delay line is mostly idle. Independent clocks are not. Redstone cost tracks simultaneous state changes and scheduled updates per tick, and only loosely tracks how many components exist.

Rules for Farms That Do Not Melt the Server

You do not need to remove every circuit. You need to know which ones run when nobody is watching. Our measured costs suggest a few rules that hold up in practice:

• Count simultaneous state changes per tick, not blocks placed.
• Replace thousands of small clocks with one central clock and a distribution bus.
• Slow a clock from 1 tick to 4 ticks where the farm still keeps up; the savings are large.
• Avoid 0-tick and 1-tick novelty circuits on a production server. They are pure overhead.
• Gate 24/7 builds behind a player-presence or chunk-loaded check so they sleep when idle.
• Profile before deleting anything, and test at realistic chunk and entity load.

Paper settings matter at the edges, not the core. Lower simulation distance trims entity and block ticking work, and entity activation ranges reduce idle mob costs, as covered in view distance vs simulation distance. None of those flags removes redstone work from a loaded chunk. Chunk loaders deserve separate scrutiny because they keep circuits awake, which is why chunk loader cost is worth reading before you place one.

Quick checklist. Is the build running when nobody is nearby? Is the chunk force-loaded? How many state changes per tick does it produce? Does it need to run 24/7, or only while someone is using it? Can it be batched into one clock, or gated behind a switch?

Pros and Cons: Tune the Build or Throw Hardware at It

Both approaches are valid, and the right answer depends on whether your bottleneck is redstone or everything else.

• Optimizing the farm: free, permanent, and survives a host migration. Downsides: it takes time, needs measurement, and players may resist changes to their builds.
• Buying hardware: fast and zero player friction. Downsides: it masks the cause, recurring cost, and a single-thread bound workload gains little from more cores.
• Best mix: fix the handful of circuits that burn 5 ms per tick, then buy headroom for world size and player count.

Common Mistakes to Avoid

• Counting blocks instead of updates. Our repeater line is the proof: 5,000 components, near-zero cost.
• Benchmarking with players online. Player movement, inventory, and chunk loading swamp the signal.
• Trusting one 5-second sample. Garbage collection and chunk loading produce spikes that vanish in a longer median.
• Ignoring P99. Our 5,000-observer run averaged 9.6 ms but spiked to 20.6 ms, and that tail is what players feel.
• Benchmarking an idle server. A build that costs 1 ms on an empty deck may cost 4 ms inside a busy base.
• Copying a farm without measuring it. Someone else’s schematic on someone else’s hardware tells you nothing about your tick.

Frequently Asked Questions

Measure One Circuit This Week

Tick sync is not a bug you can patch around. It is the shape of the workload, and once you measure the shape you can design around it: fewer simultaneous state changes, one clock instead of thousands, and builds that sleep when nobody is nearby. Start with the noisiest farm on your server, copy it to a test deck, and get a baseline before you touch anything.

If you want a second pair of eyes on the numbers, bring your spark profile and the tick loop reference to the table and compare what the graph says against what the build actually does.