I will explain what time nudge (TN) is.
Time nudge is an interpolation buffer for movement. Player movement, tank movement, jet movement, etc.
Here's a video of what movement interpolation looks like. Without interpolation, movement wouldn't look smooth. Interpolation fills in the movement gaps between network tick updates.
https://youtu.be/6EwaW2iz4iA?si=g_ELXBQlwS6HUp0z&t=119
Time nudge is directly tied to the game server's network tickrate. If the server tickrate is 60Hz that means the server sends a network packet to each player 60 times per second.
If a player's frame rate is below 60fps they won't be able to process 60 network packets every second. You need a framerate of 60fps or higher to process 60 network packets per second.
With a framerate below 60fps the player can't keep up with processing all the network packets and starts dropping them.
The dropped network packets causes the time nudge buffer to increase because it starts buffering more network packets from the server.
The reason time nudge starts buffering more network packets is so it has 2 or 3 extra packets in the time nudge buffer. Which time nudge uses to interpolate between player movements.
In summery, time nudge goes up if your framerate drops below 60fps because it buffers more network packets for movement interpolation.
Community Battlefield servers have a tickrate of 30Hz so on these servers you only need a framerate of 30fps.
Official Battlefield servers have a tickrate of 60Hz so on these servers you need a framerate of 60fps.
A low framerate in Battlefield is usually caused by CPU issues.
Type this into the BF6 command console to see CPU performance.
PerfOverlay.DrawGraph 1
If the yellow CPU line is rough, instead of smooth and has a number higher than 16ms. The CPU is struggling to maintain 60fps.
Posting screenshots with the network performance graph and CPU performance graph on-screen is the easiest and fastest way to trouble issues.
I just learned about someone who's running into the same trouble OP has mentioned. What you just described makes sense.
However, I am curious about the 30hz on community servers. When I go and host, I'm given the option to host locally. I am assuming that means my PC is the host (with a relay system).
So, I have two questions I'm curious if you know:
- Do locally hosted community servers also send at 30hz?
- If they happen to be faster, is there a way a user can differentiate between which community servers are locally hosted or not?
I want to add onto your statements with some speculation (READERS: ITS WHAT COULD BE HAPPENING, NOT NECESSARILY IS):
When I've done multiplayer code with games that have physics, I would rollback the entire physics world to the last ACKed frame when the client detects a desync between itself and the server. Then, I would replay all player inputs + step the physics world until we get back to the present frame. I would often find this is the most CPU intensive mechanism in the entire client. Old school games such as Quake would only rollback the player's character, which isn't good enough in many games today.
So if Battlefield is doing something similar (and I have a decent feeling they are since there's vehicles), if you're already dropping frames, this mechanism could trigger a death spiral.
Ok now just some mostly unrelated fluff about netcode:
I really hope the devs release some kind of video describing their netcode techniques with BF6, it's quite interesting to me. Lately I've gained a lot of interest in doing all gameplay on a fixed tick, decoupled entirely from the renderer, this does indeed though have a tradeoff in that it can introduce input lag. But, in an FPS game you don't need to necessarily correct the client's rotation during a desync, so mouse motion and weapon firing can be done at a variable framerate, so it's really just the position of the character that would have a bit of input lag. The camera could be moved instantly by extrapolating, and certainly a few techniques you can use between those fixed frames. Further, I prefer doing it using an Entity Component System, because it makes it far easier to spread the load across several threads and actually take advantage of the CPUs design, without making it a pain in the **bleep** for developers to reason about.
PushThruCombat - Commenting to add that during the issues, there is a "step" graph that also spikes. I believe your theory is correct. I believe some CPUs cannot cope with this in a full 64 player chaotic match, causing the death spiral you speak of. It seems like if your system EVER drops one frame it cannot catch back up. This makes perfect sense because the game runs fine upon starting a match, but crashes and burns when anything (physics/explosion happens). Then it is stuck in the spiral and the result is an unplayable experience on any graphics settings.
What would be an actual fix for this, as you seem very knowledgeable.
