is bufferbloat a thing?

[spaz1]

Hello,

I've been suffering intermittent input latency since for around a year. Playing is still manageable however I am no longer able to play at the level of skill I was at before this issue began happening. I've finally had enough and I've been trying to isolate the cause. Since the issue began occurring (I can not provide an exact date except that the problem became more frequent and is now happening nearly all the time), I've tried nearly everything that everyone tries when they enter this input latency rabbithole. BIOS tweaks, replaced all parts in my PC, etc.

3700x > 5800X3D
3070 > 6950XT

Replaced Mobo, PSU, Ram, Case.

In fact, there is no longer any single component or peripheral in my system that was present when the issue began. Logically, this leads me to conclude that the issue exists somewhere out of my PC.

After researching about network lag, I came across this phrase 'bufferbloat'. I've been on the Waveform website and used their Bufferbloat test, where I always recieve a 'C' grade. The link for the results is below.

https://www.waveform.com/tools/bufferbl ... 60c0a308c6#


The only variable which I know has changed in the last year is upgrading my internet package to full fibre, also recieving a new BT Smart Hub in the process.. I've tried wireless 2.4Ghz and 5hz, I've tried wired, and nothing makes a difference.

Everything is normal except 'Upload Latency', which no matter how many times I run the test is always on average around 200ms, reaching a max of 500ms. This is a considerable increase compared to my DL latency which is 10ms on average, with a max of 30. Now, I know that these numbers are only conducive as to when a connection is under max load, but is it possible that this is the cause of my problem?

I'm going to ring my ISP tomorrow, but I'd like some second opinions before I spend more money than I already have trying to fix this issue.

Thanks for reading and your responses.

[imprecise]

I've tested my connection at dslreports before and had A scores, but this test looks different, and I'm receiving D under gigabit and switched over to 100mbps on my network card and it dropped to F quality. Even dropping transmit/receive buffers to 128 from 1024 doesn't seem to help. [Edit: Also tried lowering MTU all the way to 1250.] This definitely matches my experience of feeling several hundred ms of lag on the upload side.... guess it's time to change ISP.

I find it strange for the CS2 console to show a solid connection with only a few packets jumping over 300ms, considering this shows a constant problem. [EDIT: I think this is due to using websockets, which is what the DSLReports site uses for testing. This does not mean you can simply trust the DSLReports test though because there is still TCP traffic happening during the game.]

I just verified while running the test and pingplotter UDP packets to 9.9.9.9, the pings were spiking along with the bufferbloat.

The ping spikes during increased upload events would also explain why the game seems mostly lag-free except when needing to do an action that affects server-sided objects.

[imprecise]

I ran some more tests... android device over wifi hitting 200-300mbit has a B rating.

I had one of the recommended devices (eero 6) to mitigate bufferbloat and connected it and tested...

Normal settings still tons of bufferbloat with score of C, turning on SQM does change the bufferbloat score to A+.

I played a few games of Rocket League and was able to hit really crisp accurate shots, but there does still seem to be some desync where the ball will be hit by cars that don't actually touch it. Overall it's much better because the inputs aren't being delayed by a constantly fluctuating 200-400ms.

[daviddave1]

This yt got rid of my bufferbloat. The router caps your speed tough al little so if u like downloading movies you should get a router that can run the "Cake" protocoll. Else it's the perfect setup to get a A+ on dslreports for bufferbloat. https://youtu.be/o-g2P3R84dw?si=DoPVniCedz-at41F

[imprecise]

It looks like mitigation can be achieved through this command:

netsh int tcp set global autotuninglevel=disabled

I just verified changing this setting and turning off SQM... throughput is about the same reduction of 10% as SQM, and I don't have to use the eero.

viewtopic.php?t=11976

Here are some UDP ping test results while running the bufferbloat test:

udppingtest.png (26.57 KiB) Viewed 6177 times

SQM Only means autotuninglevel=normal with SQM on.
Windows Only means autotuninglevel=disabled with SQM off.

Here is the result with no SQM and autotuninglevel=normal:

unmitigatedbufferbloat.png (351.97 KiB) Viewed 6110 times

[timecard]

Hope this helps.

1. BufferBloat tests are for TCP, most games use UDP. TCP can influence UDP network/system performance, load etc.

2. "netsh int tcp set global autotuninglevel=disabled" setting manipulates TCP window size behavior

3. UDP doesn't have a window size.

UDP_header.jpg (22.26 KiB) Viewed 6158 times

tcp_header.jpg (48.57 KiB) Viewed 6158 times

4. UDP is typically a stateless protocol, send the packet and hope it gets there (no guarantee). TCP validates packets are received, otherwise they can be resent.

5. Pingplotter, traceroute using UDP/TCP instead of ICMP (default) acts as follows:
- It sends UDP packets but expects ICMP (ping) response back to say ICMP Port Unreachable
- ICMP can report many different errors depending on what packets are sent and to what, e.g. network unreachable or no route to host
- In this case its sending a UDP packet to something that isn't listening/waiting for it the router by network standards responds with sorry - Port Unreachable (in the ICMP message) so its still relying on ICMP vs true UDP end to end, Using iperf is probably your best bet to test UDP.
- Sending unsolicited UDP packets to something over the internet will look like scanning activity and potentially be throttled. (denial of service protection etc)

[cursed-gamer]

Hope this helps.

1. BufferBloat tests are for TCP, most games use UDP. TCP can influence UDP network/system performance, load etc.

2. "netsh int tcp set global autotuninglevel=disabled" setting manipulates TCP window size behavior

3. UDP doesn't have a window size.
UDP_header.jpg
tcp_header.jpg

4. UDP is typically a stateless protocol, send the packet and hope it gets there (no guarantee). TCP validates packets are received, otherwise they can be resent.

5. Pingplotter, traceroute using UDP/TCP instead of ICMP (default) acts as follows:
- It sends UDP packets but expects ICMP (ping) response back to say ICMP Port Unreachable
- ICMP can report many different errors depending on what packets are sent and to what, e.g. network unreachable or no route to host
- In this case its sending a UDP packet to something that isn't listening/waiting for it the router by network standards responds with sorry - Port Unreachable (in the ICMP message) so its still relying on ICMP vs true UDP end to end, Using iperf is probably your best bet to test UDP.
- Sending unsolicited UDP packets to something over the internet will look like scanning activity and potentially be throttled. (denial of service protection etc)

Also keep in mind that you will not test UDP latency properly if clocks on the server and your PC are not synchronized

[timecard]

That's correct if the testing method includes timestamps in the verification process, receiver includes timestamp and that is checked etc. Otherwise you might have something that uses high resolution timestamps on send and waits till it gets response back and checks it's own time again.

[akylen]

Im not the op but mine is like this

https://www.waveform.com/tools/bufferbl ... dba3195dce


im not a an expert so i dont know if there's a problem.

[JustNumber]

I am on bufferbloat A with 3 different routers and 2 ISP . One ISP is only for my pc.Still input lag haha