MSPT does not affect non-ticking view distance

[DeSinc]

The non-tickiong view distance will just stay locked at the maximum and keep going up and up and up to the top even when the server is falling over at 14 TPS.

Expected: when MSPT goes over 47, the non-tick view distance reduces

Actual result: Even when MSPT goes above 70ms (14tps) it never reduces and in fact just keeps on raising to the maximum without stopping.

Is the MSPT measurement only affecting sim distance? MSPT is just pinning it at max distance even if I set MSPT to reduce to >1ms it just ignores this value completely and raises non-tick view distance to the maximum, lagging the server. I think it's only setting non ticking view distance by the loaded chunks, and totally ignoring MSPT for that value entirely. This seems like a bug to me.

[DeSinc]

Additional info: Server running Paper 1.20.2 (build 234) with latest 1.5.7 VDT

Tested values: default MSPT values (40 -- 47) Both default Mixed and also tested Reactive measurement methods in the config Also tested: min MSPT 1 max MSPT 5 Non tick view dist increasing to maximum value, server lagging at 14-17 TPS

min MSPT 400 max MSPT 500 No effect, non tick view dist still locked at maximum value and increasing while server lagging

The old TPS based system would lower non-ticking view distance when TPS went below a specified value like 19.5 TPS for example. This system worked correctly and lowered non tick view distance when TPS lowered and kept the server responsive as expected. The new system appears to only listen to total loaded chunks and only raise or lower non-tick view distance based on that figure alone, and not listen to miliseconds per tick.

[froobynooby]

Hey, yes you are right the MSPT settings only affect simulation distance - this was also true when the plugin used TPS instead of MSPT (unless you mean before no-tick view distance was a thing where "view distance" meant what "simulation distance" now means).

The reason the MSPT settings only affect simulation distance is that, conceptually, no-tick view distance is meant to be "free" as far as MSPT goes. So purely on that conceptual basis, it wouldn't make sense to adjust it based on MSPT. Of course the reality is that no-tick view distance does affect MSPT, and I do plan on making reactive mode work with no-tick view distance at some point.

The issue is trying to meaningfully adjust both the simulation distance and view distance at the same time (two variables) to target a certain value of MSPT (one variable). The approach I'm probably going to settle on is having the plugin maintain a configurable fixed ratio between view distance and simulation distance (e.g. a 2:1 ratio would target a view distance which is at least double the simulation distance). Interested if people have thoughts on this.

[DeSinc]

I see what you mean. It is a bit strange that it affects it when it should just be sending chunks and then being finished..

One idea I had thought of was you could reduce sim distance until it hits minimum first, and only then start leeching the non-ticking view distance, but that would effectively mean you're at minimum sim dist almost permanently at the whim of your maximum non-tick which isn't ideal.

your idea of doing a ratio, perhaps you could do that except make it the ratio between the max sim dist and the max non-tick view dist. so for example, max sim = 10, max non-tick = 24, ratio is 10:24 so it proportionally takes 2.4x the blocks from non-ticking, maybe even saving a float in the background to round to int on the final conversion so you can track the decimal changes or something. (this would mean 20 sim 20 nontick would both only reduce by 1 so it would be slower than 6/32 which would be mega fast)

even simpler, just take away 10% of the current dist each check, so 32 non tick max dist goes up and down by 3.2 chunks each check and when it gets to 10 it only goes down by 1 from there - problem is 29 -> 32 is a big change that could backflip the moment it happens because of all the extra chunks that loads so maybe only reduce by 10%, but increase by 1

(another idea) you could make the two reduce relative to how close they are to their pro-active loaded chunk limits. so if nontick is closer to its limit of 5720 total loaded chunks then it would reduce first and so on until loaded sim chunks is closest to the limit then it reduces sim chunks by 1 instead

[froobynooby]

I've done some initial work to add the feature in the PR linked above (there's a jar download there if you wanted to test). I've just gone with the configurable ratio method for now because it's the easiest, but I think I might use your idea of using the ratio between the max view distance and sim distance later on as that seems like a sane default choice. Might just need to have a floor for it though because there's a lot of people who set max view and sim distance to 32

[DeSinc]

P.S: I just tested the latest build now on my server, set the new reactive and MSPT going up still only affects sim distance. I set the new setting use-reactive-view-distance: true and tested using a very low MSPT value to make it change the view dist easier. All that changed up and down was the sim distance from 4 -> 6 -> 4 etc. not the non ticking view distance still. It stayed at 32 permanently the entire time when I believe it is meant to go down.

here's my config I think it has some of the weird changes I was making to try get it to change but no dice like lowering the mspt collection period etc. config.yml.txt

[froobynooby]

Are you using the latest build of the main branch? Reactive view distance won't work on that build because I haven't merged the feature yet. I've just uploaded a new jar to the PR here if you want reactive view distance on1.21

[DeSinc]

Ah my mistake! yeah I just tested that build and it works perfectly, that's great.