Bufferbloat = network lag/desync. Memory latency = input lag

Everything about latency. This section is mainly user/consumer discussion. (Peer-reviewed scientific discussion should go in Laboratory section). Tips, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Fishie
Posts: 39
Joined: 03 Aug 2023, 15:04
Contact:

Re: Bufferbloat = network lag/desync. Memory latency = input lag

Post by Fishie » 11 Sep 2026, 02:40

BARGHEST wrote: ↑
08 Sep 2026, 14:53
Want to try an experiment? If you have 4 RAM modules, remove 2 of them and leave them sitting around for a week. Once the week is up and you reinsert the RAM module that was previously in use, you’ll experience a temporary improvement lasting anywhere from an hour to a day—unfortunately, the duration varies from person to person. This also works with all peripheral devices. I personally experienced a temporary improvement that lasted two days. Before New Year’s, everyone decorates their homes with string lights—I hung them over two windows and plugged in extension cords, and I also connected the Christmas tree to the extension cord near the PC because it was simply closer. So who knows what the problem is and why the peripherals give a brief boost… Check this out—it’s way better and safer than heating up the RAM with a hair dryer, like trying to “train” it, ha ha.
:D :D :D :D
i just switched my display port cable and yeah, i can immediately tell mouse feels so responsive and not floaty, its gonna last only 1 day. sad

edit: it only lasted 2 hours lol
Programmer, Gamer, Discord: cat.noir

vnb
Posts: 108
Joined: 04 Nov 2025, 14:44

Re: Bufferbloat = network lag/desync. Memory latency = input lag

Post by vnb » 11 Sep 2026, 11:29

jassine wrote: ↑
10 Sep 2026, 13:17

I tried iperf3 and here are my results, they look ok but the desync issue is killing me (behind server feeling)
thank you for posting your result. I assume you are on a cable plan (coax) looking at your values? am i correct?

Honestly if you are on Fiber those values are not very good, for coax cable they are okayish. IMO on fiber you should be below 0.050ms UDP jitter anything higher means something sus is going on especially on a 10mb load...
chipotlechicken wrote: ↑
11 Sep 2026, 01:52


Do you experience UDP jitter with perfect waveform bufferbloat scores?

If thats measurable than sure I have no issues acknowledging it can cause issues.

But not everything is network related, you just need to fix your network so you can fix what else is messing with your system.

Fixing my network first was a funny experience because I got to feel my system's lag without my network lag, and although it's impossible to figure out which ones which when both are happening simultaneously, when one is isolated it does show different behavior.

It was like having training weights on every since one of my movements. But the hitreg was still okay.

But anyways im curious as to how you are having network issues with your fibre connection with a perfect bufferbloat. Are they putting you on CGNAT?
No i'm not behind a CGNAT and i don't use any smart queue management algorithm. Yes i experience more jitter on the provider with better bufferbloat because it has a weaker BGP and uses worse routes. You can have a perfect bufferbloat score, if the route your ISP use is oversaturated it will be more jittery anyway; that is why i recommended you to look for a tool called "Looking Glass" in the first place.

So essentially UDP and TCP are handled totally differently by ISPs. You can have TCP bufferbloat (waveform bufferbloat) without affecting UDP, because some ISP put higher priority on UDP. Not always the case of course. Most treat both protocols the same way.

Some even encapsulates IPv4 into IPv6 (hello Germany and USA) which is good for security but an absolute horror show for online gaming because it causes MTU mismatches and higher overhead + added latency.

Some countries also use deep packet inspection (Ukralne, Turkiye, Poland and others that i can't recall right now), which add another layer on top... Most ISP under "Liberty Global" also used deep packet inspection at a certain point, not sure if they all still do nowadays.

I mean it's case dependent really, you have to thoroughly test each ISP independently over tons of things and see, because after all it depends how it's handled in their infrastructure. In your case it might be that your ISP was treating UDP and TCP as "same priorities", which is very common nowadays unfortunately; so fixing your bufferbloat also fixed your UDP shenanigans hence why it feels better for you.

Also, I recommend you to do some research on "IP pools" for your particular ISP. Some IP ranges get shorter routes than others. the easiest way to do it if you have no Looking Glass at hand is like this: take about 5 IP addresses for reference do a winMTR for each and save each result. Turn off-on your modem or lauch a new PPPoE session -- to get another IP address in a different pool -> meaning if your first adress is lets say 61.XX.XXX.XXX try to get a number that is far from that for example : 128.XXX.XX.XXX you will be in another IP range.

Obviously ISPs have many datacenters so by getting an IP from another range you will most likely route your packets from another Point of Presence. Then use the 5 IP addresses of reference in winMTR and check the result. Same result? Try to get another IP rinse and repeat until you get an IP that routes packets differently.

jassine
Posts: 67
Joined: 21 Jan 2024, 10:38

Re: Bufferbloat = network lag/desync. Memory latency = input lag

Post by jassine » 11 Sep 2026, 11:58

vnb wrote: ↑
11 Sep 2026, 11:29

thank you for posting your result. I assume you are on a cable plan (coax) looking at your values? am i correct?

Honestly if you are on Fiber those values are not very good, for coax cable they are okayish. IMO on fiber you should be below 0.050ms UDP jitter anything higher means something sus is going on especially on a 10mb load...
well it is FIBER (600 up/200down) !!!
vnb wrote: ↑
11 Sep 2026, 11:29
Also, I recommend you to do some research on "IP pools" for your particular ISP. Some IP ranges get shorter routes than others. the easiest way to do it if you have no Looking Glass at hand is like this: take about 5 IP addresses for reference do a winMTR for each and save each result. Turn off-on your modem or lauch a new PPPoE session -- to get another IP address in a different pool -> meaning if your first adress is lets say 61.XX.XXX.XXX try to get a number that is far from that for example : 128.XXX.XX.XXX you will be in another IP range.

Obviously ISPs have many datacenters so by getting an IP from another range you will most likely route your packets from another Point of Presence. Then use the 5 IP addresses of reference in winMTR and check the result. Same result? Try to get another IP rinse and repeat until you get an IP that routes packets differently.
i have found some ips that work perfectly, no delay, nothing, the issue is i cant get them again after 24h, is there a way to force my ont to connect to them only ?

vnb
Posts: 108
Joined: 04 Nov 2025, 14:44

Re: Bufferbloat = network lag/desync. Memory latency = input lag

Post by vnb » 12 Sep 2026, 11:12

jassine wrote: ↑
11 Sep 2026, 11:58
vnb wrote: ↑
11 Sep 2026, 11:29

thank you for posting your result. I assume you are on a cable plan (coax) looking at your values? am i correct?

Honestly if you are on Fiber those values are not very good, for coax cable they are okayish. IMO on fiber you should be below 0.050ms UDP jitter anything higher means something sus is going on especially on a 10mb load...
well it is FIBER (600 up/200down) !!!
vnb wrote: ↑
11 Sep 2026, 11:29
Also, I recommend you to do some research on "IP pools" for your particular ISP. Some IP ranges get shorter routes than others. the easiest way to do it if you have no Looking Glass at hand is like this: take about 5 IP addresses for reference do a winMTR for each and save each result. Turn off-on your modem or lauch a new PPPoE session -- to get another IP address in a different pool -> meaning if your first adress is lets say 61.XX.XXX.XXX try to get a number that is far from that for example : 128.XXX.XX.XXX you will be in another IP range.

Obviously ISPs have many datacenters so by getting an IP from another range you will most likely route your packets from another Point of Presence. Then use the 5 IP addresses of reference in winMTR and check the result. Same result? Try to get another IP rinse and repeat until you get an IP that routes packets differently.
i have found some ips that work perfectly, no delay, nothing, the issue is i cant get them again after 24h, is there a way to force my ont to connect to them only ?
who is your ISP?

have you tried an Iperf3 UDP test on a few servers? maybe on the one you tested it was on an oversatured route. Can you do the test again on a 100mb load then a 10mb load and compare the result? Try different servers.

On fiber the jitter on a 10mb UDP load should be below 0.050ms... Not gonna lie your result is not great. are you directly connected to the modem? No switch in-between?

What is the reference of your GPON ONT?

i did not understand your last sentence? you mean your IP lease is 24h? are you on IPoE or PPPoE ?

Post Reply