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
1 Like
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.
1 Like
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.
EDIT:
Here's my mtr to the test server in Amsterdam
# dig t56.dslreports.com
;; ANSWER SECTION:
t56.dslreports.com. 85988 IN A 5.153.60.125
# mtr -b -y 1 -o "LSD NBAW MX" 5.153.60.125
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. 62.154.0.0/15 62.155.246.77 (62.155.246.77) 0.0% 101 0 5.6 5.2 6.1 29.6 1.3 24.1
5. 217.224.0.0/11 217.239.47.14 (217.239.47.14) 0.0% 100 0 9.7 9.3 10.2 24.7 1.3 15.2
6. 62.156.0.0/14 62.157.249.186 (62.157.249.186) 0.0% 100 0 10.1 9.5 9.9 12.6 0.2 2.8
7. 129.250.0.0/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. 129.250.0.0/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. 213.198.0.0/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. 169.45.0.0/19 ae5.cbs01.xn01.fra01.networklayer.co 47.5% 100 47 10.4 10.1 10.7 14.5 0.6 4.2
11. 169.53.0.0/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. 169.53.0.0/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. 50.97.0.0/19 ae5.dar02.sr01.ams01.networklayer.co 0.0% 100 0 26.0 14.2 33.2 75.8 12.7 47.5
14. 159.253.128.0/19 po2.fcr02.ams01.networklayer.com (15 0.0% 100 0 14.4 14.1 17.4 73.1 5.7 58.8
15. 5.153.0.0/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