Concurrent Chunk Management Engine

Concurrent Chunk Management Engine

2M Downloads

Chunk loading depends on TPS

MaixGit opened this issue ยท 10 comments

commented

I'm running a 1.20.4 Fabric server installed by Pinecraft on a Raspberry Pi 5 8gb, but for whatever reason the chunk loading is tied to the TPS. When running /tick sprint at a low MSPT (~5), the chunk loading rate greatly increases compared to 20 TPS. Thus it can be eliminated that the Pi or the SD card storage is too slow, as it is able to load quickly, just not at 20 TPS.

I've been unable to find what the cause of this is, as when compared to a Paper server on the same version and world, also installed by Pinecraft, Paper loads chunks as expected (not dependant on the TPS). I ran the tests below with a fresh install of both, no plugins or mods or configuration changes other than C2ME and FabricAPI (and TabTPS to show TPS).

Recording of Fabric with C2ME:

FabricC2ME.mp4

Recording of a Paper server with the same version and world:

Paper.mp4

Additionally this used to NOT happen about a week ago, no idea what would've changed in my configuration or Pi since I was running the same mods, same world, same versions. I've got a recording of this as well if necessary.

I'd be very grateful if the cause of this behaviour was found or explained to me, as I would like to host the best experience I can for my friends.

commented

Please test with f3 open.

commented

I don't think I changed anything... and now it's improved...

I just deleted the minecraft server install, intalled a Fabric server instance with Pinecraft again, moved in my mods, config, and world, and now it has completely different chunk loading again...

Even just visually, all 3 of the tests have been different, Paper understandably because that uses it's own implementation to my knowledge, but why this discrepancy between a square and circle looking chunk loading? I also tested having C2ME disabled, and even that performed better than yesterday, with a similar square shape for the loading (though I did have all other mods enabled for that test).

The only thing I could think of is that during the Fabric install something went wrong or one of the native Fabric libraries didn't process correctly. But I genuinely have no idea, it feels completely arbitrary, I've already restarted the Pi and reinstalled Fabric and Paper multiple times. I'll keep tinkering for a bit and update here if I encounter anything.

bruh.mp4

I don't think it has anything to do with client-side, as I haven't touched anything there, and loading chunks that the server has sent but the client hasn't loaded yet (pressing F5 after not moving), loads them instantly from memory as client-side Fabric is very performant.

Apologies for the lack of consistent and repeatable results. Any idea what the different chunk loading shapes mean? Or what could've caused the loading to be dependant on TPS?

commented

So the issue is back, I changed absolutely nothing apart from installing two new mods (Better Fabric Console and Log Begone), even after removing these mods the issue stays. Doing a complete fresh install fixed the issue again, ONGOING testing though.

bruhpt2.mp4
commented

try to disable notick vd as a workaround

commented

In vanilla, there's code limiting the chunk sending speed and is updated every single tick. That limiter is known to be somewhat flaky.

Don't think this is related to C2ME if at all. Pretty sure such behavior can be present in vanilla as well. If it doesn't, vanilla probably cannot load chunks fast enough to hit the limit.

commented

I figured out the cause of this issue and it is maddening but explains why it felt so arbitrary. It has absolutely nothing to do with the server, or the client, or C2ME or any mods.

SOMEHOW for SOME reason, Minecraft detects when you're connecting from a mobile network and throttles your chunk loading rate to somehow be tick dependent. You can tell that it's most likely the server throttling this connection because of how it is tick dependant.

My router has been randomly dying recently and thus sometimes I use my mobile internet via USB tethering to have a stable and fast connection (I'm in an area that has 5G coverage). USB tethering is registered as a wired ethernet type connection in Windows, but my wifi was still enabled which reconnected when my router came back online, so Minecraft would switch between connecting to the server via my wifi and the 5G mobile tethering connection.

Apologies for the schizophrenic looking issue report but damn this issue was annoying as hell to troubleshoot. If it IS the server that's responsible for this throttling behaviour, then perhaps it could be patched out.

commented

If it IS the server that's responsible for this throttling behaviour, then perhaps it could be patched out.

It is the sever limiting the chunk sending speed. It literally works with chunks per tick. But patching it out is probably out of scope for C2ME.

commented

Fair enough, thanks for the info.

Do you know of any mods that would do such a patch on Fabric? Or specifically which function is patched by Paper so that it could be ported.

commented

I personally don't think this is an issue normally. It should not bother normal gameplay at all, given you aren't going to use /tick sprint all that often.

If you still want to patch this, I'm not aware of any mods that patch this out.

commented

The issue isn't that you have to use /tick sprint to speed up chunk loading, it's that the chunk loading is throttled regardless of connection speed on mobile internet, and flying around a building world at 1000% flight speed doesn't work very well in such conditions, having to wait for chunks to load. I'll have an ask around on the Paper Discord server.