Reactor Shutting Off Due to stuttering fuel supply
kornfan6589 opened this issue · 14 comments
Please use the search functionality before reporting an issue. Also take a look at the closed issues!
Issue description:
Reactor shuts off sometimes due to fuel supply not being consistent. Fuel used to flow into the reactor at a steady rate, leaving one of my electrolytic separators running. I expected this behavior. However, as of a recent update that i applied today, the reactor now falls behind on actually sucking in the fuel so to speak. Sometimes it takes to long to "suck in" and just shuts off due to a lack of fuel. Video below shows the behavior of the reactor. Those fuel bars in the video used to just stay all but maxed out constantly. Also noticed there are some strong limitations on universal cable now that make running lasers very difficult with just 1 cable lead, and now requires many cables to feed enough power out. This may be intended but may also be related to my issue, so worth mentioning.
Steps to reproduce:
- Make a reactor and use ultimate everything, ensure plenty of supply of fuel
- run reactor and observe "flow rate" of fuel coming into the reactor
- Also worth noting that the current server tick rate is a steady 20
Version (make sure you are on the latest version before reporting):
Forge: 31.1.87
Mekanism: 9.10.6.419
Other relevant version: 1.15.2
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
Video of fuel supply stuttering.
@bloodscon the reactor and supply lines and associated machines are within 1 chunk. also this was only a problem after upgrading from 9.10.0 to 9.10.6. But i did some testing with 9.10.4 and did not notice this issue, however i was not necessarily looking for it. It was for sure not an issue on 9.10.0
@aidancbrady List of mods here https://pastebin.com/BC7c0sKb
as far as the world file its currently 1.7 gigs and would be hard to upload. if you like to see whats going on first hand, i can email you and you can join the server with me. I do not want to post the server ip publicly for obvious reasons.
If you have some free time and are feeling generous, trying to isolate the Mekanism version that broke things would be very helpful. Go ahead and email me the server IP if you’d like, I’ll try to join at some point.
are the pipes cables crossing chunks borders as this can cause problems like that. I had an ore process setup that i did that with and the machine would only be half full or empty but the input chest was full
as soon i put the system in one chunk cleared the chest like a beast also watch how long you cable/pipe runs are if you can make the Quantum Entangloporter it's a good item to use to stop pipe that extend a distance or cross chunk borders
so ive been doing more testing....i am unable to replicate the issue until server avg tick rate goes above 40ms. On Mekanism 9.10.0 machines would run fairly smoothly even at tick rates above 50ms; however it seems they are now heavily affected by tick rate in the current version. Ive also noticed it is not just gasses going into the reactor, it is everything mekanism from fluids to gasses to item transporters. I didnt notice this before because i use a 2011 mac pro for testing (before releasing patches) that runs the server at around 25-27ms with one player on. whereas my hosting provider averages about 40ms with 1 player. Moving to a different server host is an option, however i have concern over what has changed in mekanism that it is causing fluids/gasses/energy etc to stutter at anything above 40ms (which is still 20TPS).
Because of all of this i dont have a reliable method of replicating the issue as our live server is on the current version. All i know for sure is that 9.10.0 ran smoothly even on our live server.
If it matters, i am using Apex Hosting, Open to suggestions on a faster host, as i have not been 100% satisfied with them. If my 2011 mac pro can run the server smoother, all i am really paying for is the internet connection.
One thing you could try to help track this down is install spark https://github.com/lucko/spark the forge version (https://ci.lucko.me/job/spark/) and use it to profile. I believe it can work serverside only, and you can run it with /spark sampler start and then after a while use /spark sampler stop and provide the link it gives to the results. Hopefully it may expose what the issue is.
just running spark itself gave me this
Maybe the command changed since I last used it, none the less thank you for the log. I am not sure if this is actually the cause but given our transmitter networks are being shown as going through performant and from their mod page's description:
Load Balancing for Tileentity ticks
Load Balancing for Events
My best guess is their load balancer is causing it so that our networks just aren't getting informed as often that they should be sending contents out. Would you be willing to experiment briefly without performant to see if it fixes the issue?
Edit: Or if there is a config option for those two you could try disabling those "improvements". If that fixes it you could even try re-enabling the tile entity load balancing.
I am leaving this open for now but I am pretty sure that it is performant causing this as looking at its config the event load balancing starts happening by default at 45 ms. I would be interested to see if setting the event load balancing in their config to false does in fact fix the issue though.
sorry havent had time or people to test this yet. Had our server node changed and therefore runs at a steady 20-30ms now. which is great until more people hop on. on the test server (which is just the same world file running on a local pc) i need to get enough people on to get the tick rate high enough. im going to try testing this tonight to see the results and ill report back as soon as i can. thanks for all the input!