Minecraft redstone lag: clocks and hoppers

Redstone is rarely the reason a normal survival server lags, and it is almost always the reason a technical one does. The costs are specific and predictable: hoppers that check for items every tick, clocks that never stop, pistons that move blocks and trigger lighting and neighbour updates, and long dust lines that update thousands of positions per pulse. On Paper you can make the worst of it cheaper with misc.redstone-implementation: alternate-current, hopper settings in spigot.yml and paper-world-defaults.yml, and the vanilla max-chained-neighbor-updates cap. Beyond that it is about finding the one contraption that is costing ten milliseconds a tick, and having rules that let you switch it off without a fight.

This guide is about what redstone does to the tick and how to control it. General Paper tuning is in Paper optimisation, and the farm side - villagers and mobs - is in villager and mob farm lag.

What redstone actually costs#

It helps to separate redstone into the parts that cost something, because they are fixed in different ways.

The two that dominate real servers are hoppers and clocks. Hoppers are expensive because they work even when idle; clocks are expensive because they never stop, so a contraption that would be fine for ten seconds runs for ten hours. Piston-heavy builds - flying machines, tree farms, wall doors - are spiky rather than constant: they cost a lot during a pulse and nothing in between.

Everything here only runs inside the simulation distance of a player, or in chunks kept loaded for another reason. A contraption in a base where nobody is nearby costs nothing. That matters for diagnosis: a lag spike that appears when one particular player logs in usually means their base is the source.

Hoppers: the biggest single lever#

A vanilla hopper does two jobs: it tries to move an item to the container it faces, and it tries to pull an item from the container or ground above it. The second job runs whether or not anything is there, every tick, for every hopper in every ticking chunk. Item sorters with two hundred hoppers do this two hundred times a tick.

ticks-per:  hopper-transfer: 8  hopper-check: 1hopper-amount: 1

hopper-transfer is the vanilla cooldown of eight ticks between moves. hopper-check is how often an idle hopper looks for work; at 1 it looks every tick. Raising hopper-check to 8 is one of the biggest wins available on a hopper-heavy server. The trade-off is slightly lazier pickup - an item dropping onto an idle hopper may wait a few ticks before being pulled - which almost no design notices.

hopper-amount is how many items move per transfer. Raising it makes hoppers faster than vanilla, which breaks item sorters and timing circuits that count on the vanilla rate. Leave it at 1 unless you are deliberately changing game mechanics.

Paper adds three more in config/paper-world-defaults.yml:

hopper:  cooldown-when-full: true  disable-move-event: false  ignore-occluding-blocks: false

Those are the defaults, and each one has a catch:

• cooldown-when-full: true puts a full hopper on cooldown instead of retrying every tick. Leave it on.
• disable-move-event: true skips the Bukkit inventory move event for hopper transfers. That is a large saving with many hoppers, and it breaks every plugin that listens for that event: some protection plugins use it to stop hoppers stealing from locked chests, some logging plugins use it to record transfers, and some shop plugins rely on it. Read your plugin list before turning it on, and test with your protection plugin specifically.
• ignore-occluding-blocks: true stops hoppers checking for item containers through solid blocks above them. A small saving with odd edge cases; most servers leave it.

Hopper minecarts are worth a mention: they are entities, they pick up items in a larger area, and a hopper minecart chain under a farm is fast and comparatively expensive. Water streams feeding a small number of hoppers are cheaper than a long line of hoppers under every block.

Clocks, observers and things that never stop#

A redstone clock produces pulses forever. Observer clocks (two observers facing each other) pulse every two game ticks; comparator clocks and hopper clocks run slower. The cost depends on what each pulse does: a clock driving a single lamp is cheap, a clock driving a bank of pistons pushing sand is not.

The problem is not clocks themselves. It is clocks that are left running when nobody is using the thing they drive. A sugar cane farm that fires every two minutes costs almost nothing; one built on an observer clock that fires every two ticks costs a little per pulse, sixty thousand times an hour.

Patterns to discourage or ban:

• Unswitched clocks. Every clock should have a lever or a lock. "Clock with an off switch" is a reasonable server rule.
• Observer clocks driving pistons. Fast, continuous piston movement causes block updates, lighting work and moving block entities several times a second.
• Lag machines. Contraptions built specifically to cause updates - massive piston arrays, rapid TNT, block update detectors in loops. On a public server these are griefing, and should be treated as such.

On a public server, a plugin that detects and breaks redstone that pulses faster than a threshold is a common safety net (AntiRedstoneClock is the best-known name). It works, and it will also break legitimate fast farms, so tune its threshold to what your rules allow and whitelist known builds. It is a backstop, not a substitute for rules.

The redstone implementation setting#

Redstone dust in vanilla updates its neighbours in an order that produces a lot of redundant updates. A long line of dust can trigger tens of thousands of block updates for a single change of state. Paper offers alternative algorithms:

misc:  redstone-implementation: vanilla

Alternate Current is dramatically faster on large dust circuits and produces the same results as vanilla in practice. The difference is in update order, which matters only to builds that rely on the exact order dust updates happen in - some quasi-connectivity and update-order tricks used by technical players. If your community includes people who build that kind of thing, ask them; otherwise this is close to a free improvement.

There is also a vanilla safety limit in server.properties:

max-chained-neighbor-updates=1000000

It caps how many chained neighbour updates can happen in one go before the rest are skipped. It exists to stop a contraption from freezing the server with an endless cascade. Lowering it protects against lag machines at the risk of breaking very large legitimate builds; most servers can leave the default, and a server that has been attacked by update-cascade machines can lower it, test, and adjust. Every other key in that file is covered in server.properties explained.

Pistons, duplication and the Paper exploit settings#

Pistons are where performance and fairness overlap. Vanilla allows several duplication tricks - TNT, carpet and rail duplication through pistons - which technical players use in TNT-powered tunnel bores and world eaters. Paper disables them by default, in a section deliberately named to warn you:

unsupported-settings:  allow-headless-pistons: false  allow-piston-duplication: false  allow-permanent-block-break-exploits: false

Setting allow-piston-duplication: true brings back TNT, carpet and rail duplication. It is a gameplay decision first: TNT dupers make bedrock-level quarrying and world-eaters possible, and they also make it trivial to flatten other people's builds if your protection plugin does not stop explosions. It is also a performance decision: a running TNT duper on a clock creates explosions, falling blocks and item entities continuously. If you enable it, require dupers to be switched off when unattended and keep them inside claims.

allow-headless-pistons and allow-permanent-block-break-exploits re-enable bedrock and end portal frame breaking. On a survival server with a world border and a Nether roof rule, leave them off.

Paper also nerfs some vanilla mechanics that technical builds depend on - certain sand duplication methods, for instance, are controlled elsewhere and vary by version. Before promising a technical community that a particular farm works, test it on your exact Paper build. The Paper documentation lists the current behaviour; it does change.

Finding the contraption behind a spike#

When /mspt jumps, you want a location, not a theory.

/spark profiler start --only-ticks-over 100/spark profiler stop/paper chunkinfo/paper entity list

--only-ticks-over 100 records only ticks that took longer than 100 ms, which isolates the spikes from the normal background. In the report, look under the world tick for block entity ticking (hoppers show up here), block updates and neighbour updates (dust and observers), and piston movement. Reading a spark report walks through the views.

spark tells you what kind of work, not where. To find where:

1. Check who is online when the spike happens. Lag that follows a player is their base or their farm. Ask spark for a profile while only that player is nearby.
2. Use /paper chunkinfo to see how many chunks and block entities are loaded per world, and compare with and without that player online.
3. Fly over the area. Clocks are audible - the constant piston and observer sounds give them away.
4. If you have a block logging plugin, look up who placed observers, pistons and hoppers in that area recently. WorldEdit's //count over a selection gives you a hopper or observer count for a build.

Limits and rules that keep it under control#

A technical server and a casual survival server need different rules, but both need written ones.

For a casual survival server:

• Clocks must have an off switch and be off when unattended.
• No observer clocks faster than a set interval without asking staff.
• Item sorters capped at a reasonable size, and encouraged to use water streams and fewer hoppers.
• No lag machines; building one is griefing.
• Staff may switch off any contraption causing lag, and will tell the owner.

For a technical server, set limits in numbers people can design around: a hopper budget per base, a rule that world-eaters and TNT dupers run only while the owner is present, and a published simulation-distance and redstone implementation. Technical players are usually reasonable about limits they can see; they object to limits they discover by having a build break.

Per-chunk limits on hoppers or other block entities are possible with plugins (Insights is a well-known one). They are useful on public servers where you cannot talk to every builder, and frustrating on small ones where you can. Prefer conversation where you can have it.

If a server is dominated by one technical base, there is a structural answer: put technical play on its own server, or its own world with its own settings. A per-world override - <world>/paper-world.yml and world-settings.<name> in spigot.yml - lets a creative or test world run looser rules than the survival world. A full multi-server setup is in a Velocity proxy network.

On RE:NODE, the panel console takes /spark and /mspt with history and tab completion, so you can run a profile and read the result without leaving the page, and the CPU graph shows the spike against your plan's limit. CPU is a hard throttle to the share you bought: a server at 100% is slow, not broken, and never suspended for it. If a single contraption can pin it, the answer is the settings and rules above before it is a bigger plan.

FAQ#

Is Alternate Current safe to enable on an existing world?

Yes. It changes how dust updates are calculated, not what is stored in the world, so you can switch it on and off. Builds that depend on the exact vanilla update order may behave differently; test them, and switch back if something breaks.

Why does my server lag when one player logs in?

Because their base starts ticking. Anything in their simulation distance - clocks, hoppers, farms, villagers - only runs while they are near it. Profile with spark while they are online and only they are nearby, and the report will usually name the kind of work.

Do hoppers lag even when they are empty?

Yes, that is the main reason they are expensive. An idle hopper still checks for items to pull. Raising hopper-check in spigot.yml makes idle hoppers check less often, which cuts that cost sharply.

Should I ban redstone clocks entirely?

No. Clocks power legitimate farms and doors. Ban unswitched clocks and clocks faster than a published interval, and require an off switch. That keeps the useful builds and removes the ones that run forever for nothing.

Can I allow TNT duplication on Paper?

Yes, with unsupported-settings.allow-piston-duplication: true in paper-global.yml. Treat it as a gameplay and grief decision as well as a performance one, and make sure your protection plugin stops explosions in other players' claims.