Odd Physics Lag With Extended Uptime

Hello, I noticed recently that during extended uptime my server’s server-side physics would start performing very oddly.

This was brought up to me by one of my friends, and I have also witnessed this. It seems that the physics specifically begin to lag, making objects moving, falling, dropping, etc very very choppy almost as if they were playing on a very low FPS. (Even with the client getting above 60 fps)

Here’s a small example of this on a vehicle:

Hopefully this isn’t too difficult to see.
Could this be due to bad networking or something related to that? I’m not so sure of a good way to debug this. (If anyone knows please let me know!)

this is normal

This is most likely due to curtime variable suffering from rounding errors because dumbasses at VALVe made it a single-precision float. And no, it’s not really fixable unless somebody would bother to go through entire source code and make necessary modifications.

Yes, it is the CurTime issue. The only workaround is to changelevel - and of course, you can pick the same map when doing so.

About every 6 hours its recommend to do a map change/restart.

72 hours :v:

Single float = 16 bit.
16 bit max = 65535.
65535 / 60 = 1092 minutes.
1092 / 60 = 18.2 hours.

You start to loose precision after 18 hours, but you should not notice it until 25 hours.

That’s not how it works. Single-precision float is 32 bits. And it has only 24 bits of precision because that’s the width of mantissa, the rest is the exponent and the sign. Now, with 24 bits you can store log10(2^24) ≈ 7.225 significant figures, which means that you’ll probably start noticing rounding errors a bit before 10^5 seconds which translates to ~27 hours (at tickrate = 66 you will have Δcurtime ≈ 0.015 which requires 3 decimal places and at this point you have only 2 available).

While your result is more or less accurate, the way to achieve it was horrendously wrong.

Wow, thank you so much for all of this insight. I never would have guessed that.
Do lower tick-rates (33 for example) have the same lag in that same period of time.
Or does it become less accurate the lower the tick rate?

CurTime() serverside is the amount of time passed since server startup, so no it wont change anything unness Volvo controls time

For tickrate = 33 you’re gonna have Δcurtime ≈ 0.03 so theoretically it should become apparent later than with tickrate = 66. I’m honestly not sure though as I’ve never actually tested this.

You should look in the source engine sources rather than thinking of theories.

If you care so much maybe YOU should look there and inform us all instead of writing useless posts.

Your theory is wrong, there you go.

I’m still interested in the information though…

I would assume that the theory is incorrect because the literal delta of curtime won’t equal the theoretical delta of curtime due to all the real-world factors, and therefore could require more precision than the theoretical…

Are you being sarcastic or stupid here? Btw if you do have an actual explanation of why it’s wrong then I’d appreciate if you show it to us because I and probably others would find it interesting.

Curtime has a little to do (among other things) with how much processor power you have and how much is being used. If you have a weak server and it’s doing lots of physics calculations, it will take longer for this problem to come up. It may seem like a small, even negligible thing, but over days it adds up.

Source: I bought a $50 junker to run some servers on, these problems only show up after ~2-3 days uptime.

Curtime is a hacky thing that valve made to approximate stuff, and for their purposes it was good enough. They never thought their engine would have to deal with multi-day uptime.

What the fuck, no? I would rather not post unverified information that just came to my head out of nowhere.

I can’t tell whether to rate funny or dumb