|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| OpenWrt.lan - 1 | 639 | 635 | 0 | 0 | 9 | 0 |
| Request timed out. - 100 | 131 | 0 | 0 | 0 | 0 | 0 |
| 10.150.148.33 - 1 | 636 | 631 | 10 | 32 | 166 | 54 |
| 10.95.153.249 - 1 | 636 | 631 | 9 | 32 | 165 | 57 |
| 10.95.153.242 - 1 | 650 | 649 | 20 | 46 | 248 | 37 |
| 10.95.156.34 - 1 | 650 | 649 | 20 | 44 | 249 | 42 |
| 209.85.173.137 - 1 | 646 | 644 | 99 | 124 | 341 | 120 |
| 108.170.253.17 - 1 | 646 | 644 | 99 | 124 | 347 | 124 |
| 209.85.248.243 - 1 | 646 | 644 | 96 | 120 | 359 | 116 |
| dns.google - 1 | 646 | 644 | 88 | 112 | 300 | 114 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
That's an interesting result. It's clear that the LAN and OpenWrt connection is fine... There's something immediately upstream of your OpenWrt device that just doesn't respond to pings... and then the immediate hop above that has on average 32ms but spikes to 166 and then again the device 10.95.153.242 has avg 46 but spikes to 248ms
What this is telling me is that your ISP itself probably doesn't have very good congestion control, and there might not be much you could do at your OpenWrt device. However it's possible you can drop that first 166ms spike through SQM, it depends on what the device that doesn't respond to pings is actually.
Yes, I agree, the trouble starts between OpenWrt.lan and the next hop, basically the link that sqm should be i control of...
Now, according to the earlier tc -s qdisc output, cake did not notice such bad delays, so this might be happening in the docsis/cable plant, but I have zero experience trying to debug docsis issues...
well there is the mysterious device that doesn't return pings (kind of the opposite of the Monty Python device right?)... So OpenWrt may be handling the link between itself and that device fine, but the link upstream of that device is congested... basically as you say inside the cable infrastructure.
(In case anyone doesn't know the Monty Python reference: https://www.youtube.com/watch?v=wshyX6Hw52I )
3 Likes
gimme a bucket 
then there is no solution for my high latency problem?
Switching to a different ISP 
Well recently I bought a more specific tp-link router, the archer ax20 then here the problem I have internet but I can't download anything from the play store but if I put it in AP mode if I can download and navigate my question is because
Hi, I am not sure I fully understand your question. How did you connect and configure the archer ax20 and is that your only router? Which OpenWrt version did you install?
I explain
I have the router of my isp in bridge mode that is connected to openwrt and from there connected to my tp link archer ax20 so that it distributes the internet via wireless
ISP > OPENWRT > TP-LINK AX20
here the problem I do not have internet, I mean, it is slow to download and play youtube but if I put it in access point mode it works wonderfully
Also note that when I want to change DNS I lose connection
That sounds like a double NAT condition.
Probably what you should do, except if you want to use the double NATing to make all computers on the AX20 appear as a single internal IP address for purposes of cake"s internal IP fairness mode. In most situations double NAT is just introducing additional undesired complications.
Change DNS resolution where? On client computers behind the AX20 or on the AX20 itself?
So how can I solve the double nat problem? openwrt brings that option but apparently it is unstable but I have it disabled but the tp link ax20 router if I notice that it brings it enabled, what would be the solution?
I don't know if this will help with the high latency I have
Well, I believe you are in South America, and netsurf-eu is in Europe, so the high baseline RTT is causing some issues (TCP really starts to get a bit sluggish with long RTTs and will not compete very well with TCP flows with shorter RTTs). I guess it is hard to say anything but, that your are testing oer a long and potentially congested path.
Flent can be great help in figuring out latency issues, but you need relative close by netsurf servers, and these are rare, your best bet, if you want to use flint, would be to rent a virtual private server in a nearby at a center and run your own netsurf servers there, that way you would not need to test trams-oceanic distances. Not that measuring over long RTTs is not interesting, but unless your have latency issues with servers in Europe such measurements are not going to help much.
P.S.: If you post the flent.gz files that flent produces I could have a deeper look into the data, but I am nt sure whether that is going to help much when the test servers are too far away.
Sure, but to test your internet access link you need on measurement device on each side of the link, so one inside your home network one one outside of it.
