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.
So, based on what you just write, all players who have this problem (a lot considering the EA and Steam forums) have juste to buy a new CPU? The minimal config requirement CPU is AMD Ryzen 5 2600. So.... you just buy a 70€/$ game and you just can't play it on official servers even if you have a medium config far more powerful than the minimun requirement.. That's a shame. I really hope that can be fixed.
Was thinking the same thing,so its that simple resolving all the bad ping and packetloss problems,just buy a new cpu?sounds very odd.
AbleDark
So, I'm just speculating, I don't know enough about Frostbite's engine architecture to be really certain about things.
I'm a professional game dev, who has also done some engine dev (mostly toy engines, but I do sometimes contribute to some more serious open source stuff), it doesn't really make sense for a CPU from 2018 with 6 cores to be struggling with the gameplay code of Battlefield 6. If the official statement from the devs is to upgrade that CPU, I would say that is unacceptable.
However, assuming this is actually a problem on the devs end, you guys should be a lot more loud about this. I just recommend you do a bit more due diligence to rule out some weird stuff on your end first, more on that below.
I personally am quite impressed by their GPU work from the limited knowledge I have. Which tells me they're very competent engine engineers. So, it's probably a bug somewhere causing a death spiral. As opposed to a really bad architectural decision that requires a lot more thought and work to fix (in such cases, it just wont get fixed when management steps in).
When you think about a game engine and how it actually works, most of the heavy computations are on the GPU. A CPU is responsible for:
- physics
- character controllers are usually using kinematic physics, which is cheap computationally
- vehicles are using rigid body physics, this is more expensive, but shouldn't be an issue at all in a game like BF6
- player input
- gameplay code
- netcode (which really an abstraction, it's hard to point and be like HERE is the netcode, it has its tentacles all over)
- speculation: I posted above on how this could trigger a lot of redundant physics work during client/server desyncs
- network transport layer
- sometimes engines abstract gameplay code out to a scripting language of some sort, this almost always slower than compiled code, but there's too many things to consider to speculate further
- scheduling things and sending them over to the GPU
- particles that have physics usually means being done on the CPU, doing it on the GPU is usually just far harder architecturally
- client sided anti cheat
- note: not an expert here so I don't really know how intensive this is
When you compare to older Battlefields and other FPS games, this stuff hasn't really changed too much...which is why I have a feeling the performance issues are a bug. Like honestly, even if this stuff was all single threaded I'd still be saying the same thing.
If it's something on your end, I would check your RAM and GPU. Which you'd thing is completely contradictory to everything I just said above, but if the CPU is waiting on a response back from them it could look like the CPU is the problem.
Edit: oh and if they're for some reason saving some stuff to your storage drives too often, that would be another area, I highly doubt they're doing that though.
Edit 2: oh, I forgot, BF6 has destruction, this could be a big area of slowdown, especially if it gets looped into physics rollback code...oooooof
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.
