Chunks re-send on death, even when nearby
The bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
- Open a server (the laggier, the more noticeable)
- Connect to said server
- Wait for chunks to load
- Kill yourself without moving
→
All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
- Unresolved
What A. Guy
- 44
- 18
- Confirmed
Important
- Platform
- Chunk loading Networking Performance
- chunks death respawn
1.4.5 - 1.20.2
1.4.5 1.4.7 13w10b 1.5 1.5.2 1.6.2 1.6.4 13w38a 13w38b 13w38c 1.7.4 14w02c 14w03b 14w04a 14w04b 14w05a 14w05b 1.7.9 14w17a 14w18b 1.7.10 14w33c 14w34a 14w34b 14w34c 14w34d 1.8-pre1 1.8-pre2 1.8.1 1.8.3 1.8.4 15w45a 1.9-pre3 1.10.2 1.12-pre5 1.12.1 1.13.2 19w04b 19w05a 19w06a 19w07a 19w08b 19w09a 19w11a 19w11b 19w12b 19w13a 19w13b 19w14a 19w14b 1.14-pre1 1.14-pre2 1.14-pre3 1.14-pre4 1.14-pre5 1.14 1.14.1 1.14.2-pre1 1.14.2-pre2 1.14.2 1.14.3-pre2 1.14.3 1.14.4-pre1 1.14.4-pre3 1.14.4-pre4 1.14.4-pre5 1.14.4-pre6 1.14.4 19w34a 19w35a 19w36a 19w37a 19w38b 19w39a 19w40a 19w41a 19w42a 19w45b 19w46b 1.15-pre1 1.15-pre2 1.15-pre3 1.15-pre4 1.15-pre5 1.15-pre6 1.15-pre7 1.15 1.15.1 1.15.1-pre1 1.15.2-pre1 1.15.2-pre2 1.15.2 20w06a 20w07a 20w08a 20w09a 20w10a 20w11a 20w13a 20w13b 20w15a 20w17a 20w18a 20w19a 20w20a 20w20b 20w21a 1.16-pre2 1.16-pre3 1.16-pre5 1.16-pre6 1.16-pre7 1.16-pre8 1.16-rc1 1.16 1.16.1 20w27a 20w28a 20w30a 1.16.2-pre1 1.16.2-rc1 1.16.2-rc2 1.16.2 1.16.3-rc1 1.16.3 1.16.4-pre1 1.16.4-pre2 1.16.4-rc1 1.16.4 20w46a 20w48a 20w51a 21w03a 1.16.5 21w05a 21w05b 21w06a 21w07a 21w11a 1.17-pre2 1.17.1 21w40a 21w44a 1.20.2
Created Issue:
Chunks re-send on Death, even when Nearby
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
Example:
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidthEnvironment
Mac OS X 10.8.2 / Java SE 6 64 bit
is duplicated by
A comment with security level 'global-moderators' was removed.
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
Example:
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidthThe Bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
Example
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
The
BugWhen you die, the game will re-send all the chunks, even if the chunks are near where you died.
Example
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidthThe bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
relates to
The bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
1. Open a server (the laggier, the more noticeable)
2. Connect to said server
3. Wait for chunks to load
4. Kill yourself without moving
5. All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidthThe bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
- Open a server (the laggier, the more noticeable)
- Connect to said server
- Wait for chunks to load
- Kill yourself without moving
- All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
The bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
- Open a server (the laggier, the more noticeable)
- Connect to said server
- Wait for chunks to load
- Kill yourself without moving
- All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
The bug
When you die, the game will re-send all the chunks, even if the chunks are near where you died.
How to reproduce
- Open a server (the laggier, the more noticeable)
- Connect to said server
- Wait for chunks to load
- Kill yourself without moving
→All the loaded chunks will be scrapped, causing them to be re-downloaded from the server, using both time and bandwidth
Mac OS X 10.8.2 / Java SE 6 64 bit
Mac OS X 10.9.2 / Java SE 8 64 bit
relates to
Multiplayer / Integrated servers have very poor performace and cannot keep up even with one player on a high-end PCs / Servers / Machines
Description
Vanilla server platforms (integrated and external) are very poorly optimized and can barely run smoothly, even on a high-end hardware with higher amounts of memory allocated.
Typical, small multiplayer server drops to critically low TPS and can crash / be forcibly shut down by the watchdog (if enabled) with just a few players normally generating new chunks (in survival gamemode).
A server, using the "Default GUI" is almost impossible to run stable. When launching it via command line and allocating sufficient amount of RAM, the performance is a little bit better (and the server is not running out of memory), but the playing experience is still very rough and there is quite a lot of rubber-banding, freezes, lag spikes, etc.
How to reproduce the issues & Testing methods
Singleplayer (Integrated Server)
- Launch the game with plenty of memory allocated (4GB is usually more than enough)
- Enter into a world or create a new one
- If creating a new world, initially there are extreme framerate drops (probably client-side issue), the integrated server is rubber-banding and skipping ticks
- Start exploring the terrain around and perform the usual things (generating / loading new chunks, dropping item entities, etc.) - There will be noticable stuttering, lag and rubber-banding when punching mobs or making redstone circuits, for example
- If the player is in creative mode (or spectator mode) then everything becomes much worse
If you are playing in a survival world for long enough (assuming there are animal pens / farms, some mob grinders, chest rooms with item frames and similar) the world will run much slower and this can cause issues with redstone circuits, influence on the gameplay and so on.
Multiplayer (Vanilla platform, without any mods / tweaks / changes)
- Start a server on a relatively powerful hardware with sufficient amount of memory allocated (4GB again, would be probably more than enough)
- Join the server, along with a few other players (2-4 players at the same time is normal, 5+ will be a bit heavier)
- Start playing as usual (exploring around, interacting with entities, mobs, items) - There will be clearly noticable rubber-banding and lag spikes, which usually result in stuttering entities, desyncing issues between the clients and the server and other
If some of the players start to generate new chunks on creative mode, the server will most likely crash.
Testing methods & RAM allocation
Tested and experimented with many combinations of JVM heap sizes (amount of memory allocated), using the default, "recommended" start-up command line:
java -Xms<Initial Memory>M -Xmx<Max Memory>M -jar <Server Jar>.jar nogui
(Xms = Starting Memory / Xmx = Maximum Memory)
- Xms1024M / Xmx1024M
- Xms2048M / Xmx2048M
- Xms3072M / Xmx3072M
- Xms4096M / Xms4096M
- Xms6144M / Xmx6144M
- Xms8192M / Xmx8192M
- Xms1024M / Xmx2048M
- Xms1024M / Xmx3072M
- Xms1024M / Xmx4096M
- Xms1024M / Xmx6144M
- Xms1024M / Xmx8192M
- Players at the same time: 1-3, 3-5, 5-10
Usual activities during the tests:
- Exploring the terrain around in survival mode, creative mode (for a while), spectator mode (just for the experiments, not expecting actual results)
- Interacting with mobs, entities, armor stands, droppping and picking up item entities
- Placing water and lava (creates many block updates)
- Small, medium and advanced redstone circuits (light, piston, hopper updates)
- Small, medium and large mob farms / grinders
- Updating gravity-affected blocks (sand, gravel, concrete powder)
- Entering different dimensions and teleporting items, mobs, entities through portals
- Transfering small and large amounts of items through hoppers
- Loading previously generated and alredy saved chunks
The RAM & CPU usage (especially) was abnormally high for very small and short activities or sometimes none at all. Not only chunk generation is causing the more serious issues (but mainly it is).
Conclusion
The main reason for most of the issues is not exactly the TPS drop / loss / poor server performance, but client-side ticking, updates and synchronization.
Other games (clients) handle the updates, coming from the server in different way.
If the server can't keep up with the consistend update rate / tick rate, then the client should enable some sort of "interpolation" and increase slightly the delay between the changes (updates).
The Minecraft client runs at hardcoded 20 TPS and waits for the next tick from the server. If it is synchronized (matches with the incoming client update / tick) then it runs normally.
But even if the server drops to 19.99 TPS - There is desynchronization once in a while and this can create issues (mainly client-side).
Overall, the server performance should be definetly optimized more and some things can be tweaked.
Related issues: MC-117611, MC-44385, MC-4890, MC-342, MC-54026
This might actually be the same issue as MC-4890, not sure.
Can confirm.This is the most annoying bug for me because my friend host a small server and its laggy when i die, i must wait the MultiplayerChunkCache to max before i can play without lag
Best to reproduce in default world (superflat are lagless)
Confirmed in 1.5pre
confirmed for 15w45a
confirmed for 1.9pre3
It is a (less than useful) workaround for the some of the ghost blocks (
MC-72248,MC-5694) and strange F3+A behaviour (MC-96142).Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.
Status is set to postponed, meaning it's not needed to be up to date as a fix won't be attempted anytime soon.
Affects 1.12 - Pre-release 5
Affects 1.12.1
Still in 19w06a
Still in 19w07a
Still in 19w08a
Still in 19w09a
Still in 19w11a
Still in 19w11b
Still in 19w12b
Still in 19w13a
Still in 19w14a
Still in 1.14 Pre-Release 1
Still in 1.14 Pre-Release 2
Still in 1.14 pre-3 and 1.14 pre-4
Still in 1.14 pre-5
Still in 1.14 Release
Still in 1.14.1 Release
Still in 1.14.2 Pre-Release 1 and 1.14.2 Pre-Release 2
Can confirm for 20w27a
Can confirm in 1.17.1 Release Candidate 1.
Can confirm in 21w40a and 1.17.1
Affects 21w44a