Your ISP’s power-saving settings may be interfering with your hit registration.
-
andrelip
- Posts: 178
- Joined: 21 Mar 2014, 17:50
Your ISP’s power-saving settings may be interfering with your hit registration.
I bought a mini PC to use for CakeQoS so I could eliminate bufferbloat while still maximizing throughput. Normal routers usually cannot do both at the same time.
With bufferbloat out of the way, one interesting thing I found is that my ping under load dropped by up to 3 ms on average. The CS2 graph usually has some small noise, but now it is perfectly flat on both the upstream and downstream. Without the load it is not even with qos. This only happens when I’m really pushing things hard, such as during a network stress test using almost the full bandwidth. With light loads, there is no difference. It also usually behaves more like an on/off switch than a linear increase.
3 ms may sound small, but that is only the average. What may actually be happening is full pauses plus batching, which is much worse and can affect prediction and buffering (look up CS2 receiving margin). Jitter is worse than base latency because high base latency is at least predictable.
Hit registration improved a lot, and the receiving margin became stable. For now, the workaround is to use QoS together with iperf3 uploading 300 MB to the ISP. The mini PC already has idle disabled (C0 all the time) and interrupt moderation disabled, so according to the AIs, the source of the issue is likely the GPON on my end or on their side. I tried contacting them, but had no luck. I also tried SSHing into the ONT, but had no luck there either. It happened with two different ISPs I tested.
I’m sharing this anyway because it is the first measurable “tweak” I’ve experienced in years. It’s not mouse input lag, but it may explain the frustration many people have when playing online matches, and it will also affect inputs that need server validation, such as movement.
If anyone has an idea for how to keep it “awake” without having to push 300 MB, that would help a lot.
With bufferbloat out of the way, one interesting thing I found is that my ping under load dropped by up to 3 ms on average. The CS2 graph usually has some small noise, but now it is perfectly flat on both the upstream and downstream. Without the load it is not even with qos. This only happens when I’m really pushing things hard, such as during a network stress test using almost the full bandwidth. With light loads, there is no difference. It also usually behaves more like an on/off switch than a linear increase.
3 ms may sound small, but that is only the average. What may actually be happening is full pauses plus batching, which is much worse and can affect prediction and buffering (look up CS2 receiving margin). Jitter is worse than base latency because high base latency is at least predictable.
Hit registration improved a lot, and the receiving margin became stable. For now, the workaround is to use QoS together with iperf3 uploading 300 MB to the ISP. The mini PC already has idle disabled (C0 all the time) and interrupt moderation disabled, so according to the AIs, the source of the issue is likely the GPON on my end or on their side. I tried contacting them, but had no luck. I also tried SSHing into the ONT, but had no luck there either. It happened with two different ISPs I tested.
I’m sharing this anyway because it is the first measurable “tweak” I’ve experienced in years. It’s not mouse input lag, but it may explain the frustration many people have when playing online matches, and it will also affect inputs that need server validation, such as movement.
If anyone has an idea for how to keep it “awake” without having to push 300 MB, that would help a lot.
-
sadboytunaswag31
- Posts: 13
- Joined: 09 Aug 2025, 15:57
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
andrelip wrote: ↑24 Mar 2026, 10:04I bought a mini PC to use for CakeQoS so I could eliminate bufferbloat while still maximizing throughput. Normal routers usually cannot do both at the same time.
With bufferbloat out of the way, one interesting thing I found is that my ping under load dropped by up to 3 ms on average. The CS2 graph usually has some small noise, but now it is perfectly flat on both the upstream and downstream. Without the load it is not even with qos. This only happens when I’m really pushing things hard, such as during a network stress test using almost the full bandwidth. With light loads, there is no difference. It also usually behaves more like an on/off switch than a linear increase.
3 ms may sound small, but that is only the average. What may actually be happening is full pauses plus batching, which is much worse and can affect prediction and buffering (look up CS2 receiving margin). Jitter is worse than base latency because high base latency is at least predictable.
Hit registration improved a lot, and the receiving margin became stable. For now, the workaround is to use QoS together with iperf3 uploading 300 MB to the ISP. The mini PC already has idle disabled (C0 all the time) and interrupt moderation disabled, so according to the AIs, the source of the issue is likely the GPON on my end or on their side. I tried contacting them, but had no luck. I also tried SSHing into the ONT, but had no luck there either. It happened with two different ISPs I tested.
I’m sharing this anyway because it is the first measurable “tweak” I’ve experienced in years. It’s not mouse input lag, but it may explain the frustration many people have when playing online matches, and it will also affect inputs that need server validation, such as movement.
If anyone has an idea for how to keep it “awake” without having to push 300 MB, that would help a lot.
I also use sqm for bufferbloat. This doesnt help with hit reg nor with desync as in getting ferrari peeked. this only helps against sudden ping spikes under load and packet loss. Posting this only so that someone who didnt try this buys all this stuff and wastes money and time. Ty for your Post @andrelip
-
vnb
- Posts: 113
- Joined: 04 Nov 2025, 14:44
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
Hello,andrelip wrote: ↑24 Mar 2026, 10:04I bought a mini PC to use for CakeQoS so I could eliminate bufferbloat while still maximizing throughput. Normal routers usually cannot do both at the same time.
With bufferbloat out of the way, one interesting thing I found is that my ping under load dropped by up to 3 ms on average. The CS2 graph usually has some small noise, but now it is perfectly flat on both the upstream and downstream. Without the load it is not even with qos. This only happens when I’m really pushing things hard, such as during a network stress test using almost the full bandwidth. With light loads, there is no difference. It also usually behaves more like an on/off switch than a linear increase.
3 ms may sound small, but that is only the average. What may actually be happening is full pauses plus batching, which is much worse and can affect prediction and buffering (look up CS2 receiving margin). Jitter is worse than base latency because high base latency is at least predictable.
Hit registration improved a lot, and the receiving margin became stable. For now, the workaround is to use QoS together with iperf3 uploading 300 MB to the ISP. The mini PC already has idle disabled (C0 all the time) and interrupt moderation disabled, so according to the AIs, the source of the issue is likely the GPON on my end or on their side. I tried contacting them, but had no luck. I also tried SSHing into the ONT, but had no luck there either. It happened with two different ISPs I tested.
I’m sharing this anyway because it is the first measurable “tweak” I’ve experienced in years. It’s not mouse input lag, but it may explain the frustration many people have when playing online matches, and it will also affect inputs that need server validation, such as movement.
If anyone has an idea for how to keep it “awake” without having to push 300 MB, that would help a lot.
I have noticed the same thing with Fiber here. This phenomenon is called Dynamic Bandwidth Allocation (DBA). Essentially it is an algorithm in the OLT (ISP side) which grant upstream slots based on reported queue status.
Simply said: the more data you upload, the more the OLT grant your ONT based slots time.
It is like if a teacher will give more attention to the kid that talks a lot in class and less attention to the quiet one (the ONT that does not upload a lot).
How to trigger the DBA ? Simply saturate your upload for a couple dozens of seconds by doing upstream speedtest or anything else and the algorithms kicks in.
Now you are surely questioning :
"if i saturate my upload speed then the OLT will give my ONT priority over neighbours ONTs that doesn’t upload as much?" Well the answer is yes but only for a specific amount of time written by the ISP in the OLT firmware. This could be a few microseconds to a couple of seconds maximum, never more.
I work for the biggest fiber ISP in my country and i have had lots of discussions with engineers about similar topics. Sometimes when an OLT is saturated ( about 64 clients on the OLT, then they will tweak the DBA to be less aggressive so it will kick in but slower, etc)
Can you share your ONT exact reference ? I know that some ONT and OLT brands can sometimes conflict or not understand each other perfectly (for example Huawei ONTs over Nokia/Alcatel OLT gaves us lots of issues related to DBA and other headaches as well).
-
andrelip
- Posts: 178
- Joined: 21 Mar 2014, 17:50
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
That’s exactly what I’m doing. I’m using iperf3:vnb wrote: ↑24 Mar 2026, 21:19Hello,andrelip wrote: ↑24 Mar 2026, 10:04I bought a mini PC to use for CakeQoS so I could eliminate bufferbloat while still maximizing throughput. Normal routers usually cannot do both at the same time.
With bufferbloat out of the way, one interesting thing I found is that my ping under load dropped by up to 3 ms on average. The CS2 graph usually has some small noise, but now it is perfectly flat on both the upstream and downstream. Without the load it is not even with qos. This only happens when I’m really pushing things hard, such as during a network stress test using almost the full bandwidth. With light loads, there is no difference. It also usually behaves more like an on/off switch than a linear increase.
3 ms may sound small, but that is only the average. What may actually be happening is full pauses plus batching, which is much worse and can affect prediction and buffering (look up CS2 receiving margin). Jitter is worse than base latency because high base latency is at least predictable.
Hit registration improved a lot, and the receiving margin became stable. For now, the workaround is to use QoS together with iperf3 uploading 300 MB to the ISP. The mini PC already has idle disabled (C0 all the time) and interrupt moderation disabled, so according to the AIs, the source of the issue is likely the GPON on my end or on their side. I tried contacting them, but had no luck. I also tried SSHing into the ONT, but had no luck there either. It happened with two different ISPs I tested.
I’m sharing this anyway because it is the first measurable “tweak” I’ve experienced in years. It’s not mouse input lag, but it may explain the frustration many people have when playing online matches, and it will also affect inputs that need server validation, such as movement.
If anyone has an idea for how to keep it “awake” without having to push 300 MB, that would help a lot.
I have noticed the same thing with Fiber here. This phenomenon is called Dynamic Bandwidth Allocation (DBA). Essentially it is an algorithm in the OLT (ISP side) which grant upstream slots based on reported queue status.
Simply said: the more data you upload, the more the OLT grant your ONT based slots time.
It is like if a teacher will give more attention to the kid that talks a lot in class and less attention to the quiet one (the ONT that does not upload a lot).
How to trigger the DBA ? Simply saturate your upload for a couple dozens of seconds by doing upstream speedtest or anything else and the algorithms kicks in.
Now you are surely questioning :
"if i saturate my upload speed then the OLT will give my ONT priority over neighbours ONTs that doesn’t upload as much?" Well the answer is yes but only for a specific amount of time written by the ISP in the OLT firmware. This could be a few microseconds to a couple of seconds maximum, never more.
I work for the biggest fiber ISP in my country and i have had lots of discussions with engineers about similar topics. Sometimes when an OLT is saturated ( about 64 clients on the OLT, then they will tweak the DBA to be less aggressive so it will kick in but slower, etc)
Can you share your ONT exact reference ? I know that some ONT and OLT brands can sometimes conflict or not understand each other perfectly (for example Huawei ONTs over Nokia/Alcatel OLT gaves us lots of issues related to DBA and other headaches as well).
```bash
iperf3 -c {server_ip} -p 30000 -b 300M -t 0
```
But that will probably end up getting me banned.
ONT Model: EG8010
I need at least 50MB/s for it to have some impact. The jitter goes to 0.2ms after that.
---
sadboytunaswag31: It’s not SQM that’s doing the magic. That is just necessary to avoid bufferbloat while saturating the bandwidth.
You need a good router if you want to use CAKE QoS specifically and still be able to saturate the link... in my case, 1 Gbps down / 300 Mbps up.
-
DudeBeFishing
- Posts: 42
- Joined: 30 Oct 2022, 14:14
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
I noticed this same issue with my ISP when testing for bufferbloat. I get slightly lower latency when my connection is under load. Download saturated is about 1ms lower. Upload saturated is about 2-3ms lower. I tested random game servers using GamePing from Mudfish while running the Waveform bufferbloat test.
ISP: Verizon FIOS
ONT: I-211M-L
Router: Mikrotik CCR2004-16G-2S+PC
ISP: Verizon FIOS
ONT: I-211M-L
Router: Mikrotik CCR2004-16G-2S+PC
-
vnb
- Posts: 113
- Joined: 04 Nov 2025, 14:44
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
Not a fan at all of Huwei ONT or anything else made by them related to network tbh. They gave us so much issues when i was Working at that big ISP.
ONT Model: EG8010
I need at least 50MB/s for it to have some impact. The jitter goes to 0.2ms after that.
So much compatibilities / conflict issues with every OLT that are non-Huawei... Not sure where you are from or who is your ISP but I can bet there is 80% chance if you are in Europe that your ISP uses Nokia / Alcatel OLTs.
If your ISP allows it ditch that Huawei EG8010 ONT and go rather with a Nokia G-010G-Q ONT, they are extremely reliable and common. You can find them for dirt cheap money on Ebay.
Last edited by vnb on 30 Mar 2026, 06:30, edited 3 times in total.
-
vnb
- Posts: 113
- Joined: 04 Nov 2025, 14:44
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
damn that ONT is a unit. Never seen that ONT here in EU. But if you are on a XGS PON / GPON that is shared (99.5% of people are) then this is common, unfortunately.DudeBeFishing wrote: ↑25 Mar 2026, 09:47I noticed this same issue with my ISP when testing for bufferbloat. I get slightly lower latency when my connection is under load. Download saturated is about 1ms lower. Upload saturated is about 2-3ms lower. I tested random game servers using GamePing from Mudfish while running the Waveform bufferbloat test.
ISP: Verizon FIOS
ONT: I-211M-L
Router: Mikrotik CCR2004-16G-2S+PC
Personally I have noticed that especially on the Upload. If i saturate my upload, latency goes down by 2-3ms and hitreg is considerably better. This is just the Dynamic Bandwidth Allocation (DBA) algorithm kicking-in and giving your ONT more upstream slots.
-
MontyTheAverage
- Posts: 179
- Joined: 11 Nov 2021, 06:39
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
Ok I am not very technical with it but could this be related with the my desync, hit reg and input lag sometimes minimizing a lot whenever I get on a WhatsApp call while on an online match in different games?
The issues are also minimal whenever I play the first match of a game, when I switch between networks or restart it. Also sometimes having something serious playing in the background like a YouTube video also minimizes the issues for a bit but the issues creep back up.
The issues are also minimal whenever I play the first match of a game, when I switch between networks or restart it. Also sometimes having something serious playing in the background like a YouTube video also minimizes the issues for a bit but the issues creep back up.
-
vnb
- Posts: 113
- Joined: 04 Nov 2025, 14:44
Re: Your ISP’s power-saving settings may be interfering with your hit registration.
wdym switch between networks? you have two ISPs? you are throwing way too much infos that are all over the place.MontyTheAverage wrote: ↑29 Mar 2026, 21:55Ok I am not very technical with it but could this be related with the my desync, hit reg and input lag sometimes minimizing a lot whenever I get on a WhatsApp call while on an online match in different games?
The issues are also minimal whenever I play the first match of a game, when I switch between networks or restart it. Also sometimes having something serious playing in the background like a YouTube video also minimizes the issues for a bit but the issues creep back up.
About the DBA algorithm i was talking about above that is affecting GPON and XGSPON you can’t really do anything (except uploading data continuously, which is undoable in the long run). This is a symptom of shared PON unfortunately.
About the whatsapp thing you said and from a ISP point of view (and my experience in EU) dunno how it is done in NA. But this was actually a thing here in EU, especially in some countries like Portugal, Germany and Belgium iirc. Basically when a VOIP service was detected on your network, the ISP gives you a slight edge priority to your packets but this was about 10 years ago, i don't think it is still implemented nowadays in fixed internet here...
