Chunk Generation Performance Regressed by 20-30%

We need your environmed: OS and Java version, and your graphics card drivers.

I allows me to post here, the problem is explained by MD_5, extremely serious.
I am owner of a Spigot Server 1.9, my players can not explored the map without creating powerful lag. My server has never suffers from lag before moving to 1.9, it is urgent to address this problem, especially as MD_5 has already preparation.

Mojang it really should worry about this problem that makes Minecraft experience in multiplayer unplayable and causes disgust.

I hope the problem will be resolved quickly. Thank you for your work.

@unknown that's not relevant to this report. This has nothing to do with a client. It's a developer to developer report, which we devs do not have an alternate tracker to report to so this is only place.

The java OS and drivers would be listed as "All"

I can confirm the above mentioned issues. And again can confirm this is not client related it is a serious issue with the game itself. Again another server where players CANNOT explore previosly un generated chunks as it causes major TPS and renders the server unplayable.

1.9.1 needed ASAP

Can agree with the comment above. Players cannot explore whatsoever, and it is an irritating issue to force them to stop when TPS goes dramatically low because of these unexplored chunks.

Please fix ASAP.

Having the same issues on my server. Even with a pregenerated world loading chunks creates ridiculous lag

Any news ?

Doesnt look like it. Guys this is a serious issue that needs to be fixed. Can we assign this issue soon

@unknown we don't assign issues to mojangsters, they do that them selves

Absolutely by "we" I meant the team of devs. It would be great to see some activity on this major issue. It effectively renders the game unplayable if players explore - which im sure you understand and agree is a fundamental part of the minecraft experience that currently servers are struggling to deliver. It's somewhat disapointing to see a game breaking issue, that has a fix provided in the original report to still have NO progress made on it 😞

The issue has been open for less than a week, and they have many other high-priority issues to fix that didn't make it into 1.9. The change that caused this issue was made deliberately, and presumably for a good reason. The fix provided may help Mojang in understanding and fixing the issue, but probably can't just be dropped into the original code due to obfuscation, and they may not want to fix it in that way for the same reason they made the change in the first place.

The Minecraft development team doesn't make heavy use of the project management features of JIRA, such as assigning issues, because they don't have a lot of people to coordinate between, and can do so informally or using other internal tools. Issues are frequently fixed without being assigned, or are assigned and then fixed shortly thereafter, rather than being assigned in advance. The tracker is here primarily for their benefit, and not as a means of publicly displaying their development activity.

It is inconceivable that this problem because so let's say it's a problem, is not fixed quickly, and indeed I began worried that no solution is found at present.

Is desirable that this infamous bug chunk of generation is repaired quickly.

It's unfortunate that they do not keep us updated on whats going on. I disagree this is not a high priority issue and I will leave it there. Thanks for the advice that this system is not worth using to watch tickets.

@unknown

"The change that caused this issue was made deliberately, and presumably for a good reason. The fix provided may help Mojang in understanding and fixing the issue, but probably can't just be dropped into the original code due to obfuscation, and they may not want to fix it in that way for the same reason they made the change in the first place."

Actually, us developers will look at code, see 2 things that appear to do the same thing, but miss the slight difference in the 2, or worse, don't clearly see what happens deeper in the flow.

So we then say "let's simplify things! Delete the extra". We test, and everything works... So it seems like a good idea. Deleting code usually is a good thing.

But in this case, the problem isn't seen until larger servers, and until Mojang starts testing updates against 100 player servers...It's going to rely on the 3rd party community to clean up the mistakes, as we're the ones that have in depth profiler data on how the code behaves under heavy load.

The devs don't copy and paste our patches directly of course, but they'll know how to apply it based on logic (hince "paper patch 78" was mine [except for the part that got modified and caused bugs] as well as 2 other performance changes I contributed that landed in 1.9)

Ok, but when can we hoped that our servers again become playable?

You can use Paper server which contains the latest fixes to 1.9 performance problems (some spigot doesn't have atm)

https://aquifermc.org/threads/paper-for-1-9-official-release.51/

Actually, us developers will look at code, see 2 things that appear to do the same thing, but miss the slight difference in the 2, or worse, don't clearly see what happens deeper in the flow.
So we then say "let's simplify things! Delete the extra". We test, and everything works... So it seems like a good idea. Deleting code usually is a good thing.

If you have two functions that do mostly the same thing, then your code is poorly structured, and it's likely that changes or fixes that should be applied to both will only be applied to one, causing bugs. Mojang may not have considered the performance impact of consolidating the two functions, and may not have consolidated them correctly, but consolidating them was still a good action to take. Maybe an additional argument should have been added, or maybe the unload queue shouldn't be managed within that function at all.

@unknown, I didn't say that this wasn't a high-priority issue, only that it wasn't the only one. Everyone always thinks their favorite issue is the most important, and that the developers should drop everything else to work on it, but it's clearly impossible for them all to be right. In this case, I would argue that the official Minecraft server software is generally not sufficient for servers with a large number of players, and that most of them run alternative server software, such as the Paper server @unknown has mentioned.

MODS, My server is not a large server we have a community of around 30 players and an average online count of 6. At no point have I suggested I run a "large" server. I Never have more than 12 online at a single time and so if the official minecraft server software is not sufficient enough for that then we have far greater issues than chunk generation. This underlines even more so how important this issue is for the devs to be working on and not adding elytra sounds! The idea that I run some huge server is just wrong and being used as a reason as to why the game is not working correctly. The fact is your game is horrendously broken and the priorities of the devs seem to be WAY off the mark. Having tested the issue on the same hardware I used problem-free for 1.8. The issue is present with only 2 players online (this has been mentioned a couple of times by other members in other posts) which means the issue is NOT limited to large servers.

I do completely believe that we should be getting some actual feedback on this matter and not mods speculating as to what is going on. It seriously doesn't take much for someone who actually knows what's going on to say "Hi guys, I'm here, we're on it" however right now we are getting 1.9.1 Pre-releases with no fixes listed that match the report and no feedback on this ticket.

I understand this particular one is a heavy undertaking when compared to adding elytra sounds as it needs a total rework. It feels like its just being ignored in favour of an easier ride. You say mojang resolve things internally, while this may work well for them I suggest that those who report issues and aid in the game's continued improvement be given the courtesy of up to date feedback. This is my feedback on the matter for future issues as above I am no longer watching this one - getting totally fed up it. We try to help make this game better and its like everyone sticks their fingers in their ears because its to much work.

The chunk queue / calculations on server seems an awful waste of resources. Instead why not hand off the calculation to the client to come back to the server with the generated index, in that tap into the client's actual CPU cycles if it reaches a certain perf / benchmark (easily detectable).

To then counter "hacking" attempts (ie never trust the client) you then ask someone another client that's connected the server (randomly) to verify the calculations etc. If there are no other's on the server, it's only then does the server perform the calculations in a thread.

The point is, start offloading CPU cycles to the mesh network that which is player(s) to do as much as the heavy lifting as one can without impact to perf of their experience. Using a transaction pub/sub system ?

@unknown that doesn't have anything to do with this issue and would not be a good way to improve the server. That would extremely over complicate the design and make it even harder to make real optimizations.

@unknown I wasn't saying simplfying code was wrong. I totally agree that when you see things that appear to do the same thing, to condense it. I was saying that this regression was very unlikely to be intentional, and a mere side effect of the change, as you previously implied they intentionally changed the behavior of the code to always touch the unload queue, and I was saying I disagree and I believe the unload queue behavior change was merely an unintended side effect.

@unknown- Stick to managing what's in/out with SpigotMC and also to what you "know" vs "think". As that reads "I think" vs "i know", as until you can substantiate the opinion provided with provable / tested code that illustrates the ROI failures in this equation, then really, it's about offering alternative options to just "bug fixes" whilst highlighting ways a refactor or deferred by design can occur. Fact is there's a cloud of CPU's available to hand off workable tasks to clients, even if its discrete calculations that are obfuscated.

If anything why SpigotMC hasn't done an out of band patch to this issue (thus reducing constant bottle necks currently been seen) probably summarises the peak abilities being on offer here.

Scott Barnes - Keep it professional. He offered just as much substantiation as you did: none.

I do know it's a bad idea.

Minecraft servers operate on a 50ms tick rate. Network latency for any given client is going to be on average at least 100ms. Then add in round trip, processor lag on the client, delay between processing the network queues on the server, and then your suggested peer review.

Then factor in data synchronization, that the client then has to know more about data the server normally keeps to itself, increasing load and bandwidth on the network queue.

Now you're easily approaching 700 ms+ to do a single action that normally takes 1/10th of a millisecond.

This ticket is about how to modify a data structure to remove data when it no longer needs to be there. There's nothing a client can participate in logic about here.

This discussion ends here

@unknown well three things:

Firstly, see what happens when you think outside the narrowminded box - https://www.youtube.com/watch?v=JjSKqQI6Cr0&feature=youtu.be - you end up with moments like these.

Secondly, in 2008 had the same assnine response to how HD video can't work because of the roundtrip latency involved in clients negotiating between server<->client on how much CPU, GPU and Bandwidth can be consumed at intervals that reduces load on server/cloud infrastructure (and to prevent buffering)... oh...you now call this HD video online as a result of the team i was in via Microsoft (FYI we got it working to over 280million PC's during the beijing olympics and it was extremely rare you saw buffering symbols). Furthermore in SCADA style solutions where mission critical response times need to occur (think support operator staring at a screen looking for breakdowns) a 500ms-3 second response time for a visual catchup is undetected unless there's a deliberate interrupt in the users experience. So if an industrial grade emergency response solution like these can live with the existence of a 500ms - 3 in cognitive load to reactionary response... we can as well (assuming your limited theory on such matter were to come true, which it actuall wouldn't but this would involve an education process on threading, network latency compression etc etc)

The lifespan of a users behaviour at ahead-of-time chunk loading is as follows. The client makes the prediction ahead of time, generating chunks according to the intended seed/behaviour (and you can obfuscate the seed or encrypt that data better as well - but since MCP exists any client-side code is still open to hacking but there's more ways around that as well). While that client generates the behaviour client-side, it then sends back its findings BEFORE AND/OR AFTER the visual queue has been rendered or during such procedure.

All the server is doing is polling clients for verification of the truth, in that the clients return back the index associated within the Chunk with its findings, it then acts in the same capacity as Rendering nodes do in 3D rendering pipelines (you won't find this in your web developer textbooks btw, so may need to upgrade your Amazon account). The reality is the consequences vs likelihood of a client being without trust is actually lower than one would think, but just in case the server continues to apply verification protocols to ensure that the truth is always held to higher standard, in the event the truth fails and culprits are found it also can increase banning behaviour management whilst at the same time the server can then re-generate the suspicious chunk anyway only during non-peak-processing times.

That is to say, using crowd sourcing approaches you can furthermore generate chunks ahead of time while CPU's are idle, that is the client can tack onto the existing chatty packets that go between client/server that there are in a semi-idle state or what we called "refractory processing time", During this periods the server can predict players movements based on basic square root math(s) and historical data "User is x:1000,y:128, z:1000" therefore it can assume that another 1000 block radius is likely to be rendered in the next N amount of ticks, it can then ask spare CPU cycles to generate such information / data even if the user doesn't action that 1000 block radius. Keeping in mind its really a 1x time call per server per chunk ratio.

Lastly,
If i wanted a Wordpress blog update or fix, i'd respect your attempt at asserting authority, in the mean time, you play with your JavaScript/PHP toys and leave the hard thinking to the rest of us who look beyond what blind ignorant obedience has to offer.

As to how it relates to the topic at head.. simple... the chunk creation queue needs refactoring period. As all this does is put a band-aid upon a broken limb.

Can this please get assigned soon? It is still a massive problem.

Yay! You're the best, Mobius!