The chunks component can:
- Reduce the rate at which memory increases caused by chunk packets
- Prevents overflow exceptions from occurring
- Prevent chat and block network lag caused by an overflowing packet buffer (see above)
- Controls chunk sending rates for individual clients to boost it for the players it can
- Prevent packets being sent behind players before the chunks in front
If you use a plugin that depends on a Packet Listener or works with obtaining chunk packets, set 'bufferedLoader.enabled' to false in the configuration. Not doing so will result in that plugin to never receive packets. Since this feature does reduce the amount of memory allocated, I try to support as many of these plugins as possible.
Known supported plugins (you can enable the buffered loading here)
Known unsupported plugins (you can have to disable the buffered loading here)
- Raw Critics Ore Obfuscation
Memory increase rate
Previously, whenever a new chunk packet was created, it would allocate around 80 kb of memory. Having 400 chunks each, this easily reaches 32 mb of memory whenever a player joins or teleports around the world, or simply moves around. By re-using the 80 kb of memory each time, it takes away this worthless allocation of new memory, making the memory of the server more stable in general. Can be enabled and disabled in the configuration: bufferedLoader.
The rate for each player is individually calculated based on what the connection can handle. If the plugin notices that the stream can't handle all the chunks, it reduces the sending rate, the same is done in the opposite way but a bit slower. This prevents the stream buffer, a sort of list of packets to send, from overflowing and thus prevents network lag caused by a large amount of packets. You can set a minimum and maximum rate to make sure it is not sending way too slow or way too fast.
If set too low, it can annoy the player. If set too high, it can cause overflow exceptions and chat/block placement lag. I recommend values between 0.2 and 0.5 for a minimum rate. Lower values may result in players spawning in the void.
If set too low, it can limit the rate too much unneeded, if set too high it can cause the connection to be used too much or cause client chunk rendering bugs. I recommend values between 0.7 and 2.0. You can set it higher to 'get it over with' faster, or if the client is very fast, but often it is not beneficial. Setting it too low can reduce server stress, but obviously makes it take longer for clients to see their surroundings.
Previously the chunks behind the player were sent and the order in which they were sent could use some improvement. Therefore a new sending order is introduced to make this more efficient. The middle 'spotlight' can move around, while the order will stay exactly the same. This means that, first the middle 9 chunks are sent, and then other chunks as seen below. So no, when you move around it won't send the chunks behind you, as the middle changes with it. Every time a player changes chunk or looks around, the order is re-calculated.
Dynamic view distance
If enabled, it will do two things:
- Lazy-load chunks: Only load chunks when they have to be sent
- Adjust the view distance based on the amount of loaded chunks on the server
Lazy-loading can really help prevent tick lag. Previously when a player crossed a chunk border, 21 chunks (view = 10) were instantly loaded in one tick. When a lot of players are walking around, you will notice the tick rate getting less and less. Now with lazy-loading, it will load the configured sending rates per tick. So, around 2 chunks per tick. It also eliminates all the lag that occurred previously when players join, as 441 chunks are not instantly loaded now. Downside could be that entities may seem unresponsive until enough chunks are loaded.
Dynamic view distance is a basic adjustment: The view distance is calculated by reading the current amount of loaded chunks. The chunk:view pairs can be configured.
- 3 comments
Table of contents
- 1 Introduction
- Date created
- Mar 04, 2012
- Last updated
- Dec 28, 2012