That with local servers stuff suggests that SQM is working ok for you. It's very possible with distant servers that various high traffic interchanges are experiencing congestion, something you can't control.
The problem is that even with local servers the bufferbloat meter spikes to 500+ ms for 1 second and then comes back, and somehow it doenst affect the result much.
In any game i try to play (in local servers) i cant move properly because every 2 seconds my ping goes for 600ms and comes back everytime.
Where are the servers you're playing off of? Local to you? Or remote?
If everything you're trying to access is on the "other side" of some national choke point, then the fact that the choke point is choked is unavoidable. With all the video conferencing and soforth going on due to COVID it would be unsurprising to hear that the entire country of Brazil has several highly congested overseas links and nothing can be done about it.
When you do your test to "local servers" no such high spikes were recorded in your dslreports test. This suggests that the issue may be international underseas fiber cables etc, which you simply have no control over. There may be other explanations too... but this is a reasonable first guess.
They are here in brazil São Paulo, im from another state close
I can see it in the meter but its fast, they also appear in the mtr test.
I will record a gif to send.
It is very possible, but the problem is that all my friends internet are stable and i didnt see any complaint in my isp forum discussions.
was that test on wifi? The situation where it shifts from different levels is typical of changing wifi modulation. sudden ping spikes on wifi are often caused by background processes doing scans or whatever. There's a lot more going on when you're on wifi. If you're not on wifi, then those variations in bandwidth suggest something really odd going on. Do you have a mobile phone network based WAN?
Yes, but i just tested with wired, and its the same, the bufferbloat spike just like in the gif, with variations in bandwidth.
Like a mobile plan?
I meant what technology does your ISP use? Is it fiber, DSL, cable, wireless mobile, what?
my ISP uses DSL, the thing is that i have this same ISP for years and this problem started when i came back (i bring my router with me).
Conduct ping tests with the ISP's first router on their side of your DSL connection-- its IP will be the first one that traceroute finds.
that ip was the first one the list, and this is the ping test
Ping statistics for 100.122.50.187: Packets: Sent = 63, Received = 60, Lost = 3 (4% loss), Approximate round trip times in milli-seconds: Minimum = 24ms, Maximum = 627ms, Average = 52ms
I would guess this indicates a kernel issue or hardware issue, like a driver that hits a snag and hangs things up for 600ms. I don't know anything about your C60, but I wonder if anyone else has had issues with that hardware?
Okay this one has a ~600ms spike in the initial idle period. At that point sqm/cake have not really engaged at all... this also fits with cake's own pk_delay and av_delay from your first post, no sign of ~600ms delays here.
This is promising, could please you get a free registration and redo the test with a longer duration according to the recommendations in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803. I want to see whether "local" test stay spike free for longer times, so maybe you could increase the test duration (to the maximum allowed) and run, say 10 tests in a row and paste the results here?
This looks okay, but I fear that this test is not reporting the veridical worst-case RTTs, but rather some robust estimate that ignores outliers...
You had mtr running during the test? Anyway the worst RTT pattern strongly indicates something intermittent, this is not a typical overload pattern.
Please repeat your measurements with the high-res bufferbloat configuration option and longer run-times...
Is that precisely every two seconds?
BTW, that address range indicates carrier grade NAT (see https://tools.ietf.org/html/rfc6598), so one issue might be your ISPs CG-NAT AFTR's being overloaded. Do you also have IPv6 available and could switch?
These spikes will be visible in the detailed results, so no need to record animated gifs/videos (then again these are nice to look at, so thanks).
When you test wired, please completely disable the wifi radios in your router, otherwise other RF signals might interfere with your router.
Can you access the error counters in your DSL modem? Maybe the the modem sees cyclic RF ingress?
How can i do that with openwrt? my dsl modem is in bridge
Mmmh, good question, some modems still can/will report statistics in bridge mode, other's do not. What modem do you use? Maybe the manual will reveal something. Also most modems nowadays also ca act as full routers, so you might be able to configure the modem as router for a while if that allows you to look at its statistics/error counters, if just to rule out a DSL-problem. But, IMHO your issue does not look like a typical DSL problem (then gain, my experience is limited).
I'd definitely put the modem into router mode, connect it only to one PC and thoroughly evaluate the "raw" connection. This especially so you can see the signal reports. If you aren't getting subscribed rates with a basic speed test the line could be bad.
Something weird happened, i connected trought my modem via lan and managed to get the adsl line statistics, but the page kept refreshing and it was very lagy so i decided to see to the ping in cmd. I was getting the same 600ms ping spikes that i have here on the pc, maybe this could help
Here are the line stats, i will see if my modem display the error counters
Downstream Upstream SNR Margin : 27.9 23.2 db Line Attenuation : 9.7 7.5 db Bandwidth : 11296 574 kbps Max Bandwidth : 25420 1168 kbps
If you have the ping spikes when connected directly to the ISP modem this indicates the problem isn't with OpenWrt. perhaps you need a new ISP modem, or perhaps there is noise on your line and the modem can't compensate.
So you saw the same 600ms ping spikes when pinging your modem's IP address from a host behind your router or the router itself? In that case I agree with @dlakelan, this would indicate your router having issues...
About the modem statistics, thanks but I was more interested in the error counters... (The relative high SNR margin is not indicative of DSL issues, but without error counters that is a very very vague assessment)
Just want to mention that I had/have the same effect with dslreports. I noticed it 3 or 4 weeks ago and I was very surprised to see such spikes. I have not noticed any bufferbloat using the network. SQM was working fine.
Then I figured out that these spike issues were with the dslreports test. A hop on the way to the dslreport test server introduced delays and some packet loss. I decided to ignore the dslreports test result.
So I'd suggest to mtr the dslreport test server instance to establish a baseline.
Here's my mtr to the test server in Amsterdam
# dig t56.dslreports.com ;; ANSWER SECTION: t56.dslreports.com. 85988 IN A 126.96.36.199 # mtr -b -y 1 -o "LSD NBAW MX" 188.8.131.52 dns (172.22.22.128) 2020-04-02T17:18:22+0200 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Drop Last Best Avg Wrst Javg Jmax 1. ??? beaumont.home.lan (172.22.22.254) 0.0% 101 0 0.4 0.2 0.3 0.5 0.1 0.3 2. ??? sirus.home.lan (172.22.23.254) 0.0% 101 0 0.5 0.4 0.5 0.8 0.1 0.4 3. ??? 192.168.1.254 (192.168.1.254) 0.0% 101 0 1.0 0.8 0.9 1.6 0.1 0.8 4. 184.108.40.206/15 220.127.116.11 (18.104.22.168) 0.0% 101 0 5.6 5.2 6.1 29.6 1.3 24.1 5. 22.214.171.124/11 126.96.36.199 (188.8.131.52) 0.0% 100 0 9.7 9.3 10.2 24.7 1.3 15.2 6. 184.108.40.206/14 220.127.116.11 (18.104.22.168) 0.0% 100 0 10.1 9.5 9.9 12.6 0.2 2.8 7. 22.214.171.124/16 ae-2.r21.frnkge13.de.bb.gin.ntt.net 1.0% 100 1 10.1 9.3 11.0 16.5 1.6 6.6 8. 126.96.36.199/16 ae-0.a01.frnkge13.de.bb.gin.ntt.net 0.0% 100 0 15.7 9.2 11.0 28.0 2.4 18.5 9. 188.8.131.52/17 xe-1-0-0.bbr01.xn01.fra01.networklay 0.0% 100 0 8.9 8.6 9.2 16.1 0.6 6.8 10. 184.108.40.206/19 ae5.cbs01.xn01.fra01.networklayer.co 47.5% 100 47 10.4 10.1 10.7 14.5 0.6 4.2 11. 220.127.116.11/18 27.10.35a9.ip4.static.sl-reverse.com 0.0% 100 0 12.9 10.3 11.5 16.6 0.9 5.9 12. 18.104.22.168/18 30.10.35a9.ip4.static.sl-reverse.com 28.0% 100 28 16.7 15.1 21.9 55.9 5.6 40.6 13. 22.214.171.124/19 ae5.dar02.sr01.ams01.networklayer.co 0.0% 100 0 26.0 14.2 33.2 75.8 12.7 47.5 14. 126.96.36.199/19 po2.fcr02.ams01.networklayer.com (15 0.0% 100 0 14.4 14.1 17.4 73.1 5.7 58.8 15. 188.8.131.52/18 7d.3c.9905.ip4.static.sl-reverse.com 3.0% 100 3 16.5 16.2 17.4 30.4 1.7 13.9