Describe the bug

Version info
Modular routers 9.1.1-93
Minecraft 1.18.2
Plexiglass mountain 1.2.3
java openjdk 17.0.5+8 (upgraded to this in my testing to no result)

Any time I use the modular routers for anything each one currently on decreases tps significantly. With 4 active I get "Can't keep up! Is the server overloaded? Running 2251ms or 45 ticks behind" between 2000 ms > 7000 ms

Which is immediately stopped when the routers are turned off via redstone or control.

latest.log
Unfortunately the log doesn't look very useful

I have done testing and found no problem in a singleplayer world even went to the mining dimension to be sure it was the same.

How to reproduce the bug

Load Plexiglass mountain mod pack, use activator module to do anything in testing I could trigger with flipping a switch. About 4 of these and you can feel the lag as well as see in on the server log.

Expected behavior

Function without lag

Additional details

I'll do any testing necessary to narrow this problem down but at this point I dont know where to start.
I updated the windows server and java in an attempt to fix this since I needed to anyway. No effect.

Which Minecraft version are you using?

1.18

Crash log

No response

I've just pushed a new 1.18 PNC build to modmaven which does some extra chunk-loaded validation: https://modmaven.dev/me/desht/pneumaticcraft/pneumaticcraft-repressurized/1.18.2-3.4.3-SNAPSHOT/pneumaticcraft-repressurized-1.18.2-3.4.3-20221204.095002-4.jar

Would be grateful if you could test that and let me know if it helps?

Spark profiler https://spark.lucko.me/xe1V4KTM8X
There is a method or function I dont know java within the server thread java.lang.thread.run()
me.desht.modularrouters.block.ModularRouterBlock$$Lambda$27834/0x0000000803ad8630.tick() which takes 17536ms
within that function there is
me.desht.pneumaticcraft.common.block.entity.SecurityStationBlockEntity$Listener.onPlayerInteract() at 17516ms which is Pneumaticcraft and this doesn't show up nearly as taxing with the modular routers off.
Within that function the end of the chain is
jdk.internal.misc.Unsafe.park() at 17072ms

Since Pneumaticcraft seems related somehow the version for it is 1.18.2-3.4.1-131 I browsed the commits for Pneumaticcraft since that version and didnt see anything that stood out.

Interesting discovery While ftb backups 2 is doing a backup the mod does not lag at all and works perfectly once the backup finishes the mod resumes causing lag

Looking at the Spark profile, it seems like every time the PNC security station event listener checks to see what block is being interacted with, the game is trying to load a chunk (and continually trying to load chunks would definitely account for the lag). Which is odd, since I'd expect any interaction position (as taken from the event handler) to be loaded already.

Do you have the routers in a loaded chunk, but possibly looking into an unloaded chunk? The activator will activate blocks up to 4 blocks in front of it, so it could be looking into an unloaded chunk, and causing chunk load/unload thrashing?

I have tried to reproduce this without success. Four routers with activator modules flipping switches, I'm not seeing any lag or TPS drop at all. Including having the routers in a distant force-loaded chunk, looking into the adjacent (not force-loaded) chunk. So it's possible there's a third mod involved somehow?

I'll give it a shot.
Another thing I found is that if the router is able to do its action it doesn't have a as much of a problem but if it's too fast or the action doesn't do anything it will lag. in a 4 router setup where one places a log then another strips the log then another hits it with copper then one breaks it into storage, if any of the ingredients run out like wood, copper, or the axe it starts to lag horribly. Fantastic for letting me know it's out of materiel while I'm doing other stuff not so good for keeping the sanity of the other players on the server.

Happy to report that not even a trace of the lag from before, profiler looks good too and I added more routers to stress it with 5 routers that can't do what they want. Thanks a ton.

Excellent. I'll get a new release out in the next or day or so with that fix.

Still curious as to how the chunks could be unloaded when the routers were interacting, but hey. At least it's working properly now :)

Closing this, the PNC issue has been addressed.