Introduction Whello there everyone, I have been talking about writing a general reference work for lag busting since the arrival of 1.15. Here it finally is! In this post, I am going to try to explain, in the simplest of terms but to great detail, what the different types of lag are, what causes them, what their effects are, and how you can prevent them. It’s a lot shorter than the first version I wrote. It’s heavily edited, of course, but I also cut a lot of stuff out which I thought was just not interesting enough. It’s just the bare bones now. I am solely going to focus on lag as it relates to playing on a server, specifically EMC. Some stuff is different when playing in singleplayer, where client lag and server lag are sometimes the same thing. Additionally: EMC has a great amount of lag optimisations implemented, which makes some things different from the vanilla game. If you read anything here for which you have concrete evidence that it is false or incomplete, please let me know. I will make one note before you do this: most well-known YouTubers (like MumboJumbo) don’t always know what they’re talking about when it comes to lag prevention. As with anything: the only way to truly be sure is to test it in ideal conditions. If you want to be sure if a change would decrease the lag impact, or want to know what option would be better for the sever, I would highly recommend downloading a good diagnostic tool like Gnembon’s Carpet mod, to do empirical testing yourself. This is especially true if you’re making large farms or storage areas, where compromises and edge cases usually make it difficult to know in advance what will be better. This post is going to be split up in multiple parts. The first is something most of you might be already familiar with. It’s the difference between MSPT and FPS as well as some other lag indicators. If you want to, you can skip this part, but, as I’ve written it anyway, I’m going to keep it in. The second part is all about minimising lag on the client, the different things you can do in your world that can optimise performance. The third is all about minimising server lag. The forth contains some general ettiquette and best practices. But first, I want to explain who I am and why I think I am authorised to make a post like this. Who I am I am writing this as someone with a long history in technical Minecraft and lag prevention (which is usually a large part of technical play.) You might know me under my previous name Jelle68, you might not. I have, though briefly, worked together with SpaceWalkerRS and SacretRedstone to help the Mojang development team by explaining them how certain mechanics used to work, such that they could code a change in a way that contraptions worked again, and I have worked with gnembon, (when he had only ~5K subscribers) as a builder who also knew enough redstone to not break the stuff he had been working on. I am more of a builder than a redstoner nowadays, to the extent that most people in the technical community, including two of the three I named, have apparently forgotten about my existence. Despite this, I still know what I am talking about relatively well, and I to, this day, have the Minecraft record for smallest ever designed 3*3 ‘stargate’ piston door and smallest 2*2 trapdoor. (At least, the records were still standing a month ago…) Part 1: The different types of lag 1.1: The basics 1.1.1: How a server works To explain why there even are multiple types of lag I have to explain something quite a lot of you probably already know: how a server works. When you are playing on EMC, you are playing Minecraft on a physical server: There is a large computer somewhere that is running the game. It calculates the position of mobs, and how they are going to move. It calculates how different redstone components are turning on and off, and what different blocks need to be updated because of that. In short: this server runs the code of the game and all but a few things that happen in-game are calculated on the server. This server is rapidly sending you packages through the internet, these contain what the world looks like, and what has changed. When it receives those, your computer takes them and calculates how to display it on your screen. The server calculates what is where, and your computer calculates what that looks like. Additionally: your computer calculates some of the changes you make for itself, so it can display it before the server has sent the information. (Think about your own player movement, for example) The server does, however, have the final say over what is correct, and some stuff is only calculated server-side. This is what causes stuff like rubber-banding, for example. I’m going to give you an example to hopefully make it a little more clear: Let’s say you place a leaver, then flick it and activate a piston door that opens. What happens with these two systems? First you click to place a leaver, and then, that action is send to the server. Your computer subtracts the leaver from your inventory, and places it in the game world. However, this calculation is not final. When the server has received the information, it adds the leaver to the game world, and subtracts it from your inventory. After that, it sends those updates back to you. Now, these changes are final. When you then flick the leaver, you send this information to the server, and the server calculates the changes that flick causes. It calculates all the different on and off turning of the redstone components that are hooked up to that leaver, and sends that as mere changes to the world to your computer. Your computer doesn’t calculate the components turning on or off, it just displays them turning on and off. (This is all hugely simplified, but it works to explain what I need to explain) 1.1.2: TPS, MSPT and FPS. The second thing I need to explain before I can start talking about lag busting are the basic metrics we use to discuss different types of lag. The changes of the world are calculated by the server in time increments called ticks. A normal repeater powering takes two ticks, a sticky piston retracting takes three. When the server is not lagging, there are twenty ticks in a second. A simple calculation can show us that that means that a tick cannot take longer than 50 milliseconds to calculate: 20 x 50 milliseconds = 1000 milliseconds = 1 second. When the game is not lagging, there are 20 ticks every second, and no tick takes more than 50 milliseconds. You can see these ticks as the clock of the game: 20 times every second, a unit of time passes and everything in the game takes a certain amount of units of time. “Ticks per second” is usually shortened to TPS. So, if the TPS is 20, there is no server lag, and if the TPS is less than 20, there is some server lag. Milliseconds per tick is usually shortened to MSPT. So, if the MSPT is 30, there is no lag, and if the MSPT is 55, there is a slight amount of lag. MSPT is a great unit of lag because it is linear and always measurable (at least with the right diagnostic tools.) When a farm uses 10MSPT, that farm takes 10 milliseconds to calculate through every tick. This means that, if the background MSPT is 10 and you have two of these farms running, the total MSPT would be 30, and there would be no lag (30 < 50) However, if you have 5 of these farms running in the same environment, there would be some lag (60 > 50) The last metric people use is FPS, frames per second. This one has nothing to do with the server, and only with the client’s computer. If the FPS is low, that means that your client is not able to properly display the world on your screen fast enough. 1.2: The things that lag There are three different parts of the system that can cause problems. Firstly, we have connection lag, or internet lag. This is what happens when the server and your computer cannot communicate fast enough. Internet lag can manifest itself in two ways: low speed and low ping, which can be completely different in their causes and effects. I am, however, going to combine these two into “bad internet,” because I am jet to see a case where the distinction actually matters for Minecraft-purposes, as they usually are experienced simultaneously. In Minecraft, there is also what is usually called “block lag,” which is a specific issue with the code that causes specific small internet issues to have the effect of ping lag that could otherwise only be caused by a ping of 10-20 seconds. However, I am going to ignore it, since, as far as I know, there is no known fix for it, and the only YouTube video I have seen about it, by Gnembon, has been removed. Internet lag can manifest itself in many ways: Chunks not properly loading, or taking far too long to load; rubber banding; placing blocks to then not have your inventory update properly (placing blocks you shouldn’t be able to place, to then have them be removed a few ticks later;) placing blocks without the server realising it, causing you to get fly-kicked; fighting just not working at all, and many more. Then, there is server lag. This is also known as TPS lag. This is what happens when the server can no longer calculate every tick fast enough. The MSPT is more than 50, so the TPS goes below 20. The effect of this is that time seemingly slows down. See it as seconds taking slightly longer. There are now no longer 20 ticks per second, but 18, or 7. The same amount of things still happen every tick, but the amount of ticks that happen a second is decreased. Do keep in mind that this is only the server that goes slower: your computer might still be able to calculate everything quickly enough, you can still walk and mine as fast as you usually could. The server clock and the clock of your computer are desynchronised. There is a catch though: strain on the server will make it harder for the server to sent you packages, meaning that, apart from the slower world, you might also feel like you’re experiencing internet lag. With really low TPS making Minecraft become almost unplayable, like really bad internet would too. The last type of lag I’m discussing is client lag, which is what happens when your computer cannot calculate the rendering (and some other client-side stuff) fast enough, which usually effects in a low FPS or other weird playing aspects. (From Wikipedia: “In computing, a client is a piece of computer hardware or software that accesses a service made available by a server as part of the client–server model of computer networks.” Basically: your client is your Minecraft installation as it runs on your computer.) It is also theoretically possible for the TPS of your client to go below 20, but this should not happen on a PC that is able to sustain a world in singleplayer, and will therefore be left out in this post. Client lag is usually experienced as low fps, or sudden freeze frames. In more extreme cases, it will also, again, feel like internet lag. This time because your client cannot send and receive the packages well enough.
Part 2: Lag busting – the non-server kind 2.1: Minimising internet lag Internet lag should be addressed as internet problems, and basically cannot be bettered with in-game mechanics other than “more blocks require more data, less blocks placed = less data to send to your client,” which, though good-sounding in theory, has barely any effect in practice. The only thing I can recommend is a change of playing style. Fighting mobs with bad internet is far less possible than building structures. 2.2: Minimising client lag Let’s focus on client performance, what things cause it and how can you improve your situation? First of all, there are some changes you can make to your client to optimise it. You should, first and foremost, install client optimisation mods. Those are mods that greatly improves client performance. After that, you can also allocate more ram (Minecraft 1.15.2 can use up to 5GB in my experience.) by changing your profile in the launcher. It feels obvious to note, but decreasing render distance and other setting changes also help a lot. Wafflecoffee has made a good thread about that. Then, there are the changes you can make to the world that improve the client lag: basically minimising the amount of calculations your client needs to do. There are a few important and a few less important ones. First thing: minimise the amount of entities. This are item frames, paintings, mobs, items, mine carts, boats and such. A single one won’t change too much, but it tends to add up quickly. For most of these, it is obvious how to minimise the use of them, but I do want to spend some time on items, as they are often present in water streams. If your farm outputs items in item-form through water streams, it could be really worth it to slow them down for a second (letting them fall through a cobweb does wonders), to then let the water stream go where it needs to go. A stack of items is only one entity, so letting a full stack of items go through a water stream is lag-friendlier than letting 64 single items go through. This cobweb allows the items to stack. On EMC, because of the more aggressive stacking methods, just having the water stream curve around itself will work too, instead of the cobweb. I want to add that most water-based item filters cannot deal with stacked items, but, on EMC, water stream based item filters do not work reliably anyway, so that should really only be an issue in singleplayer. I would also really recommend testing this singleplayer first. Whether or not this is effective really depends on the type of output and the distance the items still need to travel in unison. This testing is made harder with the more aggressive stacking methods on EMC, but, with some tinkering, you can probably figure something out. The second thing you would optimise in your world to prevent client lag are tile-entities. These are blocks that act like entities in some way on the code-level. Generally, it are the block that store items. The ones that cause the majority of the lag are chests, hoppers and furnaces. This is idle lag: it doesn’t matter what is being used and what isn’t; their presence in the world is what causes the lag to the client. Placing droppers atop hoppers, or blocks, or even locking them doesn’t change the amount of lag they produce client-side, though stuff like this can have a positive impact on the server. The last thing you can do to prevent client lag is minimising the amount of block state changes. A redstone dust flickering on and off is a change of block state, which has to be rendered. Also notable are pistons, which’ movement can strain the client. The thing that stands out to me about client-lag optimisations is that it always feels really blunt. Less entities, less tile entities, less block state changes. There are very little caveats or little tricks to use. This is all I know about preventing client-side lag in Minecraft. There is also the standard advice that starts and ends with “buy a better computer,” but that one seems… unproductive.
Part 3: What we’re here for: minimising server lag Finally, we have arrived at the main goal of this thread, more than two and a half thousand words in. In a novel, this would be around nine pages: a modest introduction. I am going to split this up into two, but first, I need to give you one more definition. There is a distinction that I always make when lag-busting that I think is really helpful when trying to make optimisations. This is the distinction between passive lag and active lag. Passive lag is lag that is caused whenever a contraption is loaded, active lag is lag that is caused when a contraption is turned on. For a sorting system, its passive lag would be the lag that it causes when it is simply loaded, and its active lag is the lag that it causes whenever it is sorting. This is quite a useful distinction, as stuff that optimises passive lag can actually increase the amount of active lag, and vice versa. It can be really important to decide which one matters more. More on that in part 4: Lag etiquette. With that out of the way, I am going to split this part up by component. I did try to write something that also discusses full farm designs, but cut that because of length. 3.1: The component by component breakdown There is one general rule of thumb in vanilla Minecraft when it comes to which components cause the most lag: the older it is, the more lag is causes. Redstone dust and redstone torches are the most lagy, after that come comparators, pistons and hoppers, after those slime block structures, and then finally come the observers. There are, of course, a lot of caveats to this. 3.1.1: Hoppers When having exposed hoppers, it is widely known that you should place something on top of them whenever the item-picking-up functionality of them is not needed. However, there is some confusion as to which blocks should be used. Instead of telling you to use composters, and, in some cases, droppers, I am going to give you a full benchmark of every block you might think of. All these tests are done with 70 000 empty hoppers on an empty world, which was restarted between tests, running on an AMD Ryzen 9 3900x with 3200MHz CL 14 memory, by someone more qualified to do this kind of testing than me. This data was gathered in 1.14.4, but my quick testing shows it to still be similar enough 1.16, as the testing I’m going to do on hopper configurations will show. The results are the amount of MSPT those 70K hoppers needed with the given block on top. There are a few things I need to add to this graph: -Double chests were placed on 2 hoppers each. If every hopper would get its own double chest, you’d expect worse results. -“Block” is any building block without further redstone capabilities. During testing, Stone bricks were used (I think.) - A redstone block on top of a hopper locks it, meaning it can no longer transfer items. There are three main conclusions we can draw from this graph: 1: Composters instead of air / any blocks on top of hoppers gives a 75% performance improvement. 2: Barrels are better than chests when you need just some storage halfway through a hopper line as a bit of overflow. For literally any storage block, droppers are the best. 3: the large difference between furnaces and droppers, which was present in 1.12, is no longer the case in 1.14. (and 1.16,) though the difference is still significant with α = 0.05. (Don’t worry if you don’t know what that means… ) There is one caveat to this, which comes in the form of client lag. With a well-optimised client, there is little to no difference between composters and droppers, but, with a purely vanilla client on 1.16.4, there is. This testing is done with my HP Probook G7 13.3” laptop, with an i5-10210U and no dedicated graphics card, playing on a server I set up for this testing, where the world is running on my desktop. It’s the same world as the other testing I did, with 14400 hoppers (a filled Utopia res surface.) The fps is an average after letting it stabilise for a moment. [Sadly, I lost this graph and the exact numbers in it. Most of the stuff were at 20, with composters at 15 and the few stuff you expect to be low, like chests, at 5] Honestly, this change is less drastic than I thought it would be. I have, so far, I have always recommended droppers on top of hoppers for shops and residences, sacrificing a bit of server lag for better performance client-side. I still think that, for large shops, which are usually only loaded by buyers, and only by the owner when stocking, this is true, but I think that, on 1070, which is a farming res with shops connected to it, I should have opted for composters instead of droppers. We’re not done with hoppers jet. We’ve tested empty hoppers with different blocks on top: now it is time to test different hopper configurations. I will do this on my own PC, with an i5-4670, 8GB allocated DDR3 RAM, SATA SSD and GTX 960 graphics card. My client has only Carpet mod on it and all hoppers, when possible, will be topped off with composters. The first test (“empty”) is a normal empty hopper test: -The second (“line”) is that of a line of hoppers, with items in the rightmost dropper transferring items to the leftmost. Tested during a time that all hoppers were transferring items. -The third (“Clogged line”) used the same setup, except with every hopper filled up completely. -The fourth (“Empty chests”) is with empty chests on top. -The fifth (“Filled chests”) is with filled hoppers, and filled chests, all with full stacks of the same item. -The sixth (“Filled chests 2”) is with filled hoppers, and filled chests, but with full stacks of different items. This is similar to filled chests with nonstackables, like shears or shulker boxes. -The seventh (“Filled chests 3”) is with filled hoppers and filled chests, but with only one item of every item type. Something like this could happen when you’re, for example, having a clogged up system with random wool in it. This specific test is 5 single white wool items in the hopper, and 27 single stone items in the chest. -The last test is just another test with locked hoppers. Here are the results: Nothing really all too special. The hoppers with composters on top all did better than the ones with chests on top. The line is the least laggy, since the hoppers go into their cooldown all the time, but, apart from that, nothing too interesting is going on here. However, you might wonder “Where is filled chests 3?” Well, here it is: [Another lost graph. "Filled chests 3" was around 1600, compleatly dwarfing all other staff Whatever you do, just don’t do that. The problem here lies in that the hopper tries to fill every single slot, since they have stacks that could have more items in them. To do this, it checks every single slot in the chest to see if it does contain a similar item. Because it never finds any, it does this every single tick, 20 times a second, for all 5 items, for all 27 slots. That is 2700 checks per hopper per second. Luckily enough, this has been somewhat optimised on EMC, and it should not be this drastic there. However, I would still advice to avoid getting yourself into this hopper configuration whenever you can. This all concludes very simply: -Not matter what you're doing, avoid “Filled chests 3” -Place composters on top of exposed hoppers, or, when you’re really struggling client-side, droppers. (Composters also have the nice benefit of being movable by pistons, so you can still use the top of a hopper if you need it) -Lock/power your hoppers with redstone whenever you can. Okay. These 1000 words contain everything I’m going to say about hoppers. 3.1.2: Redstone lines With “redstone lines” I mean any form of signal transmission. Usually, the lag impact these create doesn’t matter at all: you turn it off or on once or twice a day, and that’s it. But, if you have a signal going through a wire every minute, or maybe even every few seconds, it might be worth the time to use a less laggy option than the normal redstone dust. Speaking about which: here is my normal redstone dust testing lay-out, all hooked up to an 8gt clock: Do do this test, I replaced the redstone and repeaters with the other stuff I'm testing Here is the Data: I think that the conclusion we can draw from this data is quite obvious: Don’t use redstone dust when you’re frequently transmitting a signal over a line. Whenever a signal must cross a distance of 20+ blocks more than once a minute, I usually just use rails. They’re not the most lag-friendly, but it’s a really sensible option. If you want to know more about how to do logic with rail redstone, check out PallaPalla’s video on it. I’m not going to bother about testing all the different options for instant wire. Just use 2No2Name’s system. 3.1.3: Pistons You thought I was done with my graphs? Oh no, I’m not. Pistons, when passive / not changing state, don’t generate any more lag than passive droppers, or locked hoppers. However, for quite a lot of farms, you want pistons to push out repeatedly. These first ones are hooked up to an 8gt clock, meaning they extend and retract every 8 game ticks, and they are powerd in the least lagy way possible: with the newest component, the observer. The second lay-out uses slime-blocks instead, pushing in the exact same amount of blocks whilst being powered in the most lag-friendly way available: repeaters. (Observers 2-tick the pistons and cause them to drop their blocks, meaning you’d have to activate the piston twice.) I used to have images of both of these, but, sadly, they got lost over the time that it took me to finally post this thing. Here are the results: As you can see, passive pistons are just completely negligible. More interesting is that pushing slime block walls is a lot less laggy than pushing normal pistons. This is quite useful information when designing a bamboo, sugar cane or kelp farm that does not use flying machines. 3.1.4: Light updates This one is just a small one, but I thought I’d quickly write it down anyway. Minecraft has two types of light: sky light and block light. The first is the light level you’d have, assuming there are no torches or similar anywhere, and the sun is at noon. The second is the light level you’d have assuming the sun or moon don’t produce any light: it only takes into account torches and whatnot. Both of these values are always calculated independently, so make sure neither frequently updates caused by your contraption. To make my point, I have made this horrendous flickering light update machine over here: This machine, with 255 flickering lamps uses 2MSPT both at night time and at day time. My fps when getting near it was a similar number, btw, showing how different client and server lag can be. Also, as you might’ve noticed: 2MSPT isn’t all that much: that is correct. Light updates are a lot less impactful to the server since 1.14. I would still advice against causing them, though, as it’s just unnecessary. 3.1.x: Room for future updates. I know, there is a lot more to talk about. There is stuff to say about minecarts and other entities, but none of that is really all that counter-intuitive, and, realistically, only two people are going to read it, and neither are going to be interested in it. The one thing I’ll say now is: don’t stack up entities on EMC. When working on my hostile mob switch (system that forces all spawn attempts for hostile mobs to fail, making the area like it was loaded in peaceful mode) I used some stacked mobs in mine carts, and the server effectively blew up. I have tested and confirmed since that EMC has issues where placing a lot of entities in one space (even when cancelling their collisions with a vine,) the server just cannot handle it, and preforms way worse than you would expect from vanilla.
Part 4: Lag etiquette / general best practices I have given you all these numbers now. Question is: what do they mean? Quite a lot of advice should be straightforward: if you make a farm, follow the necessary steps to minimise the amount of lag it causes. There are cases, however, where the steps to follow are less clear. 4.1: Spread your lag What I mean with that is that lag spikes are a lot worse than a sustained strain for the other people on the server. It’s best to spread out the straining tasks rather than to let the server do them all at once. An obvious example would be a kelp farm. Launching all flying machines at once, especially for a really large tank, causes the server to get completely overwhelmed for a while, after which it can pick up again. It can be really helpful to launce all flying machines individually, one after the other, to spread out the impact the farm has on the server. As it turns out, most of them aren’t even that impactful if you properly spread the lag out. 4.2: Don’t overproduce This is a pretty obvious one: only make as much as you need, only make the farm as fast as you can use and sell its recourses. Spreading lag is again of importance here: why make a smeltry that can smelt everything in half an hour, if you could also just make it hopperspeed and let it run whilst you do other stuff in your storage area? 4.3: Spread your farms Sadly, this is a bit more difficult on the residences of EMC, but, in the wild, this can really help. Instead of having one place where you stand and load all your farms, try to have a lot of separate areas, where you only afk if you need the output for that specific farm. This can get more difficult if you have a lot of farms and little accounts, but it can still apply. Tom and I (in planning) have our farms in groups of use. I just used the example of a smeltry, and I’m going to use it again. Tom and I have a really small smeltry in our storage area, that we use when we need to smelt just a couple of stacks, and a really large one somewhere else, that can, in a few hours, smelt DCs upon DCs, (as we sometimes need to smelt DCs upon DCs.) This larger smeltry is only loaded when it is needed. Conclusion This is a thread that has been passively on my hard drive for over a year. In the past two hours, I quickly edited it into something that I can present. A lot of stuff is still missing, either because I don’t feel like doing all the tests again to fact-check myself, or because typing it all out would take another eternity. It is a lot shorter than originally planned and it has a lot less information than originally planned, but I hope it can still prove to be helpful to some. ~Egeau
I learned 2 things on my first read through here. I expect next time I read through this there will be something else sink in.
I did not have the time to read your thread yet, but it looks like more time, research, and work went into your post than in some published research papers or thesis I have read
