NoLaggChunks
Introduction
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
Important
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)
- Orebfuscator
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.
Sending rate
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.
Minimum rate
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.
Maximum rate
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.
Sending order
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.
My favorite function ever... Maxrate: 50 :D
What is recommended maxrate/minrate? Seems awfully vague?
@Eternisrequiem
Yes, I set mine to minumum chunk sending rate to 0.1, and maximum chunk sending to 1.0. I'll test it.
NoLagg's chunk sending rate has been extremely useful for my server which is hosted on a fixed upload speed connection (with not a very high bandwidth ceiling), as it prevents a player that is receiving a large number of chunks from saturating the connection and affecting other players. This may not be the intended purpose, but without it I couldn't host a server here so I'm grateful.
I am wondering if it could be possible to add a global chunk sending rate option as well though, as it would more closely match the benefit I'm trying to get from the chunks component. For example, I would like to allocate 75% of my connection's upload bandwidth for sending chunks (since chunks can vary in size being able to specify in kb/s for the sending rate would be a nice plus too, but may be too difficult to implement). That way it doesn't matter how few or many players are requesting chunks, as the chunks for all players combined will fill up to the allocated bandwidth configured for sending them.
Having Buffered loading enabled seems to make chunk loading laggier for MC 1.7.2. But the lazy chunk load for dynamic view distance is still the most useful bit of this, makes initial chunk loads for teleports much faster.
@cartman_2000
Do you mind uploading the compiled plugin? I can't seem to get Eclipse to do it for me
Edit: Nevermind I got it, thanks!
@bergerkiller
Could you add in this plugin the feature of not sending information behind opaque blocks (at less behind opaque blocks that are below you)
Would be very interesting cause it will reduce the bandwidth use and put anti x-ray obsolete reducing more the connection stretch.
Thanks a lot.