Lag Non-contained Issues (Piston Driven Clocks)

[FriendlyGamer]

Basically if a player decides to make a mesecon "clock" with piston, mese, mesecon "wires", powerplant (or similar setup) then they can make them operate so insanely fast that it hit the CPU core's at a few % for as long one is operating.

At the rate that was noticed it would take about 50 of these simple ish devices to draw a sustained 100% CPU usage (one entire CPU core).

A few possible ideas in my mind that possibly that either the mesecon coding is not optimized or it could be that such situations where there no "definitive" speed defined (like say for the blinky plant) the devices simply will go as fast as they will without any "restraints" in place or not "enough" thus passing that to the CPU to "worry about".

Are either of my assumptions correct? If not what can I as an administrator do practically speaking at scale to cop with lagness from such?

[SmallJoker]

Are you talking about server CPU usage or client? Also consider enabling the profiler (see minetest.conf.example or main menu settings) to gather some execution time results. If mesecons takes much time to execute a step, then it's probably a mesecons issue, otherwise it's likely that Minetest needs time to prepare the new mapblocks for rendering.

[FriendlyGamer]

Are you talking about server CPU usage or client? Also consider enabling the profiler (see minetest.conf.example or main menu settings) to gather some execution time results. If mesecons takes much time to execute a step, then it's probably a mesecons issue, otherwise it's likely that Minetest needs time to prepare the new mapblocks for rendering.

Thank you very much for your reply. I did mean the server's CPU usage and since I wasn't sure on how to use the profiler to trace down lag sources... We did it when both the device was off and then when it was on. With the same exact person in the same exact in game location. So the variation that the mapblock needed time to render should not have existed, since this was server sided we noticed and we did our best to limit variables as humanly possible.

[Desour]

Fast (with delay of one globalstep dtime) gate oscillations are forbidden by overheats. Pistons are indeed lacking this. Btw. here's a screenshot (from another issue, but shows the subject):

[FriendlyGamer]

Fast (with delay of one globalstep dtime) gate oscillations are forbidden by overheats. Pistons are indeed lacking this. Btw. here's a screenshot (from another issue, but shows the subject):

So what your saying everything but pistons are "throttled" by "overheat"? If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game? Because as I said it would only takes about 50 of these to max out a core according to our testing of a single clock similar to the one above.

[Desour]

So what your saying everything but pistons are "throttled" by "overheat"?

Try connecting a not gate's output with its input. After a short time it will drop. See also: https://github.com/minetest-mods/mesecons/blob/9b58f8db29c545d5fead166ae519045d20a1ca0b/mesecons_gates/init.lua#L29-L32

If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game?

The best thing to do is probably to use mesecons.do_overheat (and overheat group) for pistons and swap them with an overheated version. The overheated piston should then not react to mesecons and after a node timer that was started when the overheated piston is constructed runs out, the overheated piston should be swapped to a normal piston again and updated to the current mesecons signal state.

Feel free to make a PR! ; ) (But note that this might be a bit more difficult than described.)

[FriendlyGamer]

So what your saying everything but pistons are "throttled" by "overheat"?

Try connecting a not gate's output with its input. After a short time it will drop. See also:

https://github.com/minetest-mods/mesecons/blob/9b58f8db29c545d5fead166ae519045d20a1ca0b/mesecons_gates/init.lua#L29-L32

If so could we implement that or something similar to prevent piston based lag machines from being as easily produce able in game?

The best thing to do is probably to use mesecons.do_overheat (and overheat group) for pistons and swap them with an overheated version. The overheated piston should then not react to mesecons and after a node timer that was started when the overheated piston is constructed runs out, the overheated piston should be swapped to a normal piston again and updated to the current mesecons signal state.

Feel free to make a PR! ; ) (But note that this might be a bit more difficult than described.)

Thanks for the information but please do keep in mind that I meant to highlight and bring up this situation on my server so people can refer to this issue and help reach a solution for the mod itself.

Which can then be applied to my and all other operating Minetest servers which are based on this mod. So hopefully someone can help us here to resolve the situation sooner or later.

[numberZero]

See also #406

[numberZero]

I’d suggest limiting piston speed instead of overheating. Sadly that’s a breaking change, there may be machines relying on instant action (I don’t remember ever seeing that actually... except of my own machines =)

[FriendlyGamer]

I’d suggest limiting piston speed instead of overheating. Sadly that’s a breaking change, there may be machines relying on instant action (I don’t remember ever seeing that actually... except of my own machines =)

Exactly and indeed better than letting people easily exploit servers' CPU resources I am not right? Even Minecraft's Redstone is throttled to allow per redstone tick which in Minecraft was every 2 in game ticks which is equal to 10ms.

[numberZero]

I think that can be configurable with possibility to keep the current behavior.

[BuckarooBanzay]

Your issue may be solved by third-party mods that provide management of the cpu-resources consumed by this mod, for example: mesecons_debug

[FriendlyGamer]

Your issue may be solved by third-party mods that provide management of the cpu-resources consumed by this mod, for example: mesecons_debug

Hey thanks for the suggestion however, checking this mod awhile ago and even now it doesn't appear to have a clear understanding of the hard coded limitation in place per mapblock and currently lack any configurations by this mod.

[numberZero]

See PR