en descarga el ping es bueno pero en subida no varia sube y baja
1 Like
Tienes que bajarle a la subida (ya sé el sacrificio pero es la única cura como tal), estás en CGNAT?
Mi isp me tenía en CGNAT y no me ayudaba mucho el SQM, después de quejarme varias veces me dieron IP pública + IPv6 y me va mejor aunque claro es fibra óptica
no me suena el nombre CGNAT si sirve de algo mi router de mi ISP es el Arris tg2482a
como veras hice la prueba en dslreports y esto me da en subida 
no es muy estable como en la descarga :
El CGNAT es cuando el ISP no te asigna una IP pública por el puerto WAN sino que te da una IP local, ahora que reviso esa vaina es DOCSIS no ADSL jaja. Tienes que poner el link adaptation en ethernet with overhead con un valor de 18, también el ack-filter en egress options dice que ayuda en ese tipo de conexión.
una duda si tengo el router de mi ISP en modo puente veras que el modelo que te mencione trae un telefono eso afectara algo o no ?
Desconozco pero supongo que el teléfono y el tv cable pasa por otra VLAN que no afecta a la velocidad del internet
Yo tengo esos ajustes y el overhead en 4 porque lo mío es fibra con VLAN
entonces hice lo que me dijistes pero empeoro creo
root@OpenWrt:~# cat /etc/config/sqm
config queue 'eth1'
option enabled '1'
option interface 'eth0.2'
option download '56185'
option upload '2985'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'default'
option overhead '18'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option ingress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option eqdisc_opts 'nat dual-srchost ack-filter'
option iqdisc_opts 'nat dual-dsthost ingress'
option egress_ecn 'ECN'
1 Like
When writing in your native language, please always provide an english translation.
This way other users all around the world can take part in the discussion and possibly benefit from the outcome, without having to use a translator.
Mmmh, okay 300ms delay (and 309.9-87.7 = 222.2 ms range) is hard to stomach for any kind of interactive game... I note that the Wrst delay is already crazy high for Hops 1 and 2 so there are nasty spikes already in the access network, but the average really jumps between hops 5 and 6 but that most likely simply reflects the physical distance between google's data center and your home (which is bad, I had picked 8.8.8.8 on the assumption that it will be in a CDN close by to rule out long path issues).
That said, I believe you ran mtr on the OpenWrt router itself, which typically is fine, but it would be better for this test to run it from a host internal to your network so we see the internal network delay as well. Could you test this again from a machine inside your network? In case you only have Windows machines, try either WSL2 and a recent Ubuntu or use WinMMTR or WinMTRCmd ...
Oops, that is something I have not noticed before, these live classes are via video by any chance?
Okay, so certainly a reaction-time limited game where latency variations are a show stopper pretty easily.
The private IP-addresses in the 10. range like 10.150.148.33 in the MTR result indicate that CGNAT is in use:
host:~ user$ whois 10.150.148.33
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
inetnum: 10.0.0.0 - 10.255.255.255
organisation: IANA - Private Use
status: RESERVED
remarks: Reserved for Private-Use Networks [RFC1918].Complete
remarks: registration details for 10.0.0.0/8 are found
remarks: iniana-ipv4-special-registry.
changed: 1995-06
source: IANA
Sure this could theoretically be a case of CGNAT overload, but that should really happen independent of his brothers using the upload, no?
Mmmh, could you please post the content of the "Share Your Results" box under https://www.speedguide.net/analyzer.php. I wonder whether your ISP might actually be using a IPv6 tunnel resulting in a 40 byte larger invisible overhead that needs to be accounted for? This is not that likely, but since we went through the low hanging fruit already, this might be worth a shot.
Just for reference here is what I see for my link:
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2020.09.04 04:46
IP address: 77.0.xx.xxx
Client OS/browser: Mac OS (Safari 605.1.15)
TCP options string: 020405ac010303060101080a769db3bb0000000004020000
MSS: 1452
MTU: 1492
TCP Window: 132480 (not multiple of MSS)
RWIN Scaling: 6 bits (2^6=64)
Unscaled RWIN : 2070
Recommended RWINs: 63888, 127776, 255552, 511104, 1022208
BDP limit (200ms): 5299kbps (662KBytes/s)
BDP limit (500ms): 2120kbps (265KBytes/s)
MTU Discovery: ON
TTL: 48
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
The most interesting part should be the MSS and MTU sizes.
1 Like
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2020.09.04 12:43
IP address: 179.7.xxx.xx
Client OS/browser: Windows 10 (Chrome 85.0.4183.83)
TCP options string: 020405b40103030801010402
MSS: 1460
MTU: 1500
TCP Window: 262656 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 1026
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 10506kbps (1313KBytes/s)
BDP limit (500ms): 4202kbps (525KBytes/s)
MTU Discovery: ON
TTL: 113
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
Thanks, so as feared this is not going anywhere, this looks like bog standard ethernet, where MTU = 1500, and for IPv4 MSS should always be MTU-20-20-X (fixed IP-overhead, fixed TCP-overhead, variable/optional TCP-overhead).
So that puts us back to mtr.
Could you repeat your load test, but this time with mtr/WinMTR running on an host internal to your network and not on the router, please. The goal here is to see whether the latency increase already happens on the way to the OpenWrt router.
And let's try sudo mtr -ezb4w -i 0.2 -c 200 www.lacnic.net this is the Latin America and Caribbean Network Information Centre which hopefully is closer than googles data centers...
|------------------------------------------------------------------------------------------|
| 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?