No FPS gaming possible

[ChristophSmaul1337]

Alright man, I understand you want your problem fixed ASAP. I'm doing my best to help you but I need a little bit of better communication from you. A little feedback is required so I can know what you've tried and what wasn't successful. So, did you do what I suggested in the last post(s)? Did you do a capture when you had no problems to compare to a capture when you have problems?

Please report back when you implement my suggestions, even when they're not successful. Otherwise, I'm in the dark about what you''ve done so I'm always left guessing. You're hyperfixating on the network aspect and all the Wireshark stuff, and I'm still not convinced it's actually the problem.

To troubleshoot this correctly, you simply have to isolate as many variables as possible. Please work with me here and report feedback. Thanks!

Don't you think the incoming packages (blue) look strange with the spikes?

So this looks more "normal" I would say, both in & out are now at 45 packets/s which is what I'd expect to see. Did you experience problems this round? Was this a good round or a bad one? How bad, exactly? Did you even notice any difference to the other rounds?

The spikes are somewhat strange but I wouldn't mind it. It looks fine, as the spikes are only 1 packet/s up or down. It's not like it's spiking do double that or dropping off to 0.

[LaggyTyp]

We can forget about the RAM.

1.) My RAM setup is bulletproof optimized + water-cooled (MORA 420)
2.) I've been playing with the default BIOS (2066MT or so) for weeks (no change)
3.) I've been playing with XMP2 (4000MT CL16) for weeks (no change)
4.) Sometimes everything works perfectly and then suddenly it doesn't.

Today I got a USB-C NIC (TPLink UE300C) and it generally feels better than my Intel I225-V (onboard), but this afternoon/evening it started again. My ping increased by about 5-6ms and my shots weren't reaching me or did little damage. When that happens, I feel like I'm not really in the game anymore. Like I'm in a cheater lobby. Right now, it's working fine again.

It's my ISP. I wish it weren't. I wish I could fix it with settings or money for hardware, but it's probably out of my hands.

[ChristophSmaul1337]

We can forget about the RAM.

Dude, I KNOW it's not the RAM. You don't get the point of this I think. The procedure I've posted isn't meant to "fix" it or provide the actual solution. Look, when you're troubleshooting stuff like this, it's important to isolate as many variables as possible. It's necessary to get everything to a baseline state, which you know works 100% of the time. Doing my suggested steps will achieve that. You have to do this with your memory, because again, its stability is temperature dependant, unlike most other devices in your computer. If you're heating it up with a test and then have it retrain at these elevated temperatures, only then you know for certain that it'll be running in a stable manner in any scenario you can throw at it, for example a 45 minute round of BF2042. It has nothing to do with running XMP or stock settings or anything, but the temperature and its effect on the memory sticks.

Again I ask you to do the steps I've listed in yesterday's post. Then, after you've done the steps with your memory, play more rounds of BF2042 and record packet captures in both scenarios, when the game feels good and when it feels bad.

We're not going to get anywhere with this unless you're willing to help me out a little bit. I'm trying my best, but your input is required here. Nothing I can do if you can't do these simple things for me. Thanks.

[LaggyTyp]

I did everything according to your instructions.

tm5.png (80.3 KiB) Viewed 913 times

The game feels like what I'm used to on a Sunday. My shots aren't registering properly. It was 50:50 for the round.

After 2042

2042.png (54.46 KiB) Viewed 913 times

[ChristophSmaul1337]

Alright, nice. Thanks. The next step would be to do the Wireshark capture again when the problem is there, and also when it's not there. When you've done that, you'd be looking for differences in the captures. You can start with the I/O graph again and post in in here. The ultimate goal is to find a consistent, reproducable difference in the packet captures which can be used as an indication if a round will be good or not.

The game feels like what I'm used to on a Sunday. My shots aren't registering properly. It was 50:50 for the round.

And that's to be expected. Again, the point of that procedure was to consistently eliminate the memory from the equation, so we don't have to think about it any more. Now, there's one less thing that could be the root cause and we don't have to worry about it. It leaves less possibilities open and makes troubleshooting infinitely easier.

[LaggyTyp]

I'll probably do the packet recordings tomorrow. Because I can't play today (Sunday), but I'll try anyway.

Thoughts:
- What if information is missing from the UDP packets?
- What if the server ignores some UDP packets (e.g., they arrive too quickly or are in the wrong order due to jitter)?
- I need a packet analysis. That is, a way to compare the contents of the packets from a good session with a bad one.

I'm truly grateful that you didn't leave me hanging here, brother! Thank you for your time. Thank you for your effort! <3

[LaggyTyp]

I should also mention: I performed the following tweaks because I thought I had a buffering problem.

NIC
- Everything disabled except interrupt moderation (interrupt moderation rate also disabled)
- Receive buffer = 1024 (2000 - 4000 feels worse)
- Transmit buffer = 512 (same as 1024)

Windows (W11 24H2)
NetworkThrottlingIndex = 90 decimal (Disabling or a lower value like "10" makes it worse)
SystemResponsiveness = 0 decimal
netsh interface tcp set global rsc=disabled
netsh interface udp set global uro=disabled
netsh interface udp set global uro=disabled

FritzBox 6690 Cable
LAN cable (5 meters)
GPU@OC = disabled (stock)
W11 ReviOS
BF2042 port enabled in the router

Something weird is:
The modulation of a DOCSIS 3.1 (upload) channel is acting up. It's supposed to be running at 512QAM, but it switches back and forth between 512QAM and 32QAM 100 to 200 times a day. Vodafone says it's not a problem, but it wasn't at the time.

[ChristophSmaul1337]

- What if information is missing from the UDP packets?
- What if the server ignores some UDP packets (e.g., they arrive too quickly or are in the wrong order due to jitter)?

I've kind of addressed both of these before, but I'll quickly go over it one more time. UDP packets not only are identifiable by their packet number, but they also have checksums. This ensures that the data packet is intact and it doesn't have missing information. You can see the checksums with Wireshark, also under the "User Datagram Protocol" section. If the checksum isn't correct, the packet is deemed faulty and will be discarded. And what do we call missing packets? Exactly, "packet loss". That's also the reason why your second thought will show itself as packet loss. Let me quote myself from earlier:

If the client sees the packets with their numbers in order like this: 1-2-3-4-5-6-7-8-9-10, it'll say that everything is fine. If there's out of order packets, your client receives, for example, this sequence: 1-3-4-5-6-7-8-2-9-10. It's missing packet #2 in the correct place because it was either lost or delayed along the way. The client knows that after packet #1, there's supposed to be packet #2, but it only sees #3 next. It can therefore deduce that a packet must have been lost. If the packet actually arrives later isn't relly important, because the information contained in packet #2 is already outdated by the time it arrives (in my example, after packet #8).

This of course works in both directions and the server also keeps track of the packets. If your data is arriving at the server in the wrong order, you'll get a "packet loss" notification, too, just in the "upload" direction. Same with the server not accepting your packets.

- I need a packet analysis.

Don't think this is necessary. Again, if packets are "damaged" somehow it'll show itself as packet loss. Also, you would know if it's severe enough as you couldn't play the game at all. As I've said before, I've played with 250 ping and 10% loss on a Japan server back in Battlefield 3 and I never had these desync problems. You'd rather see terrible lag, teleportation, rubber banding. That kind of crap, but never was my hitreg once terrible, even with these conditions, and I've never died in a weird way once. In my opinion, what you're seeing can't be explained by ping differences, jitter or packet loss, unless the issue is so severe that you'd be having trouble walking forwards in the game in the first place.

[LaggyTyp]

I understand.

Do you have any NIC or Windows settings, or is everything standard?

[ChristophSmaul1337]

Do you have any NIC or Windows settings, or is everything standard?

Everything is as standard as it gets. No changes in Windows, and I've not overclocked anything for now either, because I'm also still investigating my own problems I had and trying to come up with an explanation. All I've currently changed in BIOS is set XMP, enable Secure Boot and correcting the boot order.

And then you'll always have to consider the millions of gamers out there that have no idea what Windows even is, how anything works and god forbid change any settings. If Windows really required changes and optimizations to run well, we would have millions of people complaining every day, this forum would cease to exist because the server would be horribly overloaded with the millions of people having trouble on standard Windows installs. This doesn't happen, so Windows can't be to blame.