Please use the full command:
tc - s qdisc
So that we can see whether the Shapers are still active.
And it would be excellent, if you could also include an English translation of you Spanish text....
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 ta rget 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 8117643145 bytes 7975325 pkt (dropped 0, overlimits 0 requeues 13)
backlog 0b 0p requeues 13
maxpacket 1462 drop_overlimit 0 new_flow_count 24 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 800d: dev eth0.2 root refcnt 2 bandwidth 2Mbit besteffort dual-srchos t nat nowash ack-filter split-gso rtt 100.0ms noatm overhead 22 mpu 64
Sent 332921638 bytes 1935838 pkt (dropped 224342, overlimits 1430984 requeues 0 )
backlog 0b 0p requeues 0
memory used: 340704b of 4Mb
capacity estimate: 2Mbit
min/max network layer size: 28 / 1500
min/max overhead-adjusted size: 64 / 1522
average network hdr offset: 14
Tin 0
thresh 2Mbit
target 9.1ms
interval 104.1ms
pk_delay 18.9ms
av_delay 5.0ms
sp_delay 17us
backlog 0b
pkts 2160180
bytes 351628180
way_inds 33356
way_miss 25709
way_cols 0
drops 1489
marks 0
ack_drop 222853
sp_flows 2
bk_flows 1
un_flows 0
max_len 11888
quantum 300
qdisc ingress ffff: dev eth0.2 parent ffff:fff1 ----------------
Sent 7728798900 bytes 6707806 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 800e: dev ifb4eth0.2 root refcnt 2 bandwidth 53Mbit besteffort dual-d sthost nat wash ack-filter split-gso rtt 100.0ms noatm overhead 22 mpu 64
Sent 7826038979 bytes 6704480 pkt (dropped 3326, overlimits 6684796 requeues 0)
backlog 0b 0p requeues 0
memory used: 1243872b of 4Mb
capacity estimate: 53Mbit
min/max network layer size: 46 / 1500
min/max overhead-adjusted size: 68 / 1522
average network hdr offset: 14
Tin 0
thresh 53Mbit
target 5.0ms
interval 100.0ms
pk_delay 166us
av_delay 56us
sp_delay 12us
backlog 0b
pkts 6707806
bytes 7830435816
way_inds 47221
way_miss 24578
way_cols 0
drops 3121
marks 0
ack_drop 205
sp_flows 1
bk_flows 1
un_flows 0
max_len 23392
quantum 1514
I took this out when I was playing and suddenly the latency went up
What latency increase did you see?
Cake's egree/upload counters report 18.9ms, while single full size packet takes around 6ms, so if there are 3packetscahead of your game packet from eligeable flows you will see such latency... But I have a feelibgvyou see bigger delays in your game?
Well, I don't want to complicate my life, so I am thinking of buying this equipment, the ubiquiti edgerouter x, my doubt is that this equipment will reduce the buffer swelling?
Mmh, as far as I know, ubiquity implets something close to sqm, not sure whether they offer cake in addistion to HTB+fq_codel though. If you think about running this under OpenWrt I am not sure whether this will not have the same issues as your current router. But if you are thinking about OpenWrt and a wired only router (and use your old router as AP and wired switch) you might want to look at a raspberry pi4B (with or without an additional USB3 ethernet dongle) as that offers quite some more CPU power for a similar price than the edgerouter X...
That said, I have no first-hand experience with either edgerouter X (OpenWrt or Ubiquity's OS) nor with a RPI4B, so take my recommendations with a grain of salt...
Mmmh, one more test to run would be to use mtr to measure path latency (preferably on an endhost computer, but if not possible you can install and run it from your router: opkg update ; opkg install mtr)
ask your brothers to upload data simultaneously and what on-line how that affects the latency along your measurement path.
I would probably start by trying to measure against goggle's servers (as I assume that they will have nodes close by, but that might not be optimal from your location, so feel free to replace the measurement "server" with something close):
mtr -ezb4 8.8.8.8
Then after getting a feeling for the idle/unloaded latency to all hops, ask your brothers to upload something and keep monitoring the delay.
Do this once with SQM disabled, and once with SQM enabled...
apparently raspberry pi 4 B works with Broadcom and openwrt mentions that it has problems with its Soc and openwrt is in snapshot and apparently nothing is stable yet
Yes, the latest designated "stable" OpenWrt version 19.7.3 does not seem to offer support for the RPI4B, but current snapshots do. In my limited experience the OpenWrt snapshots typically works rather well (on my old wndr3700v2*, I have been running self-compiled master versions for ~2 years without many issues, just stopped doing that as installing OpenWrt on my turris omnia is a) not super convenient, ad b) doing so would get rid of the reason I bought the omnia in the first place, automatic updates from a source I trust).
As I said, no personal experience, but when seeing performance numbers and price of the RPI4B I was/am quite tempted to use that as primary router...
*) Once the OS on the turris got based on OpenWrt 19 I had very little reason to postpone the switchover, but still it took me half a year, since the master snapshots on the wndr3700 worked so well and reliable.
Problems with Broadcom devices are mostly on the wireless side, with their softmac wireless chipsets (which are predominantly used in routers and notebooks/ desktops). For these softmac wireless chipsets, the only honest answer is that they aren't supported and never will be. Their other chipset family is fullmac based, usually targeted at mobile devices (smartphones, tablets, ARM SBCs, very few low-end notebooks and a handful of routers). These fullmac designs have decent driver support (but the firmware might be a tad limited, especially for interface combinations --> multiple (V)AP interface) and can be fully supported by OpenWrt.
The SOC (and wired ethernet- and switch-) support state tends to be rather good (mainline even), however the usual combination with non-functional wireless chipsets (and, worse, xDSL-modem/ cable-modem/ FXS/ DECT hardware) without any driver support does have a serious effect on the amount of manpower spent on Broadcom SOCs (developers and (ir-)regular contributors). As a consequence, a lot of devices that could (at least partially, without wireless, modem, FXS/ DECT) be supported simply aren't, because too much of the hardware would remain dormant for the efforts to be worthwhile.
The RPi is a bit special in this regard, as it has free driver support and a huge (perdominantly Raspbian based) community behind it. On the one hand the full-featured Raspbian eco-system, on the other hand (much slower-) attempts to mainline support for these devices one by one, OpenWrt is somewhere in the middle here (the router specific -or non-interactive onboard- parts should be rather fine, but if you want to add displays, IÂČC, SPI, etc. peripherials, you might prefer a more desktop oriented distribution or Raspbian). For the 19.07.0 release, the RPi was announced too late, so for the time being you'll have to use snapshots (at least until 20.xy.0 gets released)
With a focus on wired router uses, the RPi4 should be full-featured with current OpenWrt/ master. The SOC is fast and can apparently do routing surprisingly fast with its USB3 networking (onboard and a second external USB3 ethernet card), it also appears to be a decent option for SQM or VPN uses. Its onboard wireless -although fully supported by brcmfac- should not be considered usable (only a single radio, so operating on either 2.4 GHz XOR 5 GHz, single-stream, tiny antennas, limited interface combinations possible), you're better left ignoring its presence for AP uses. If you do need a high-speed router (between ~500-1000 MBit/s WAN speed or doing extensive SQM/ VPN), the RPi4 (not its earlier relatives) would probably be the cheapest good option (for lower requirements you can find better devices, with 4+1 ethernet ports and good concurrent dual-band radios).
[Disclaimer] I do not own any RPi device myself.
Adding the ingress string on advanced ingress settings fixed my SQM being ineffective with Epic Store downloads lagging the entire network, it also reduced spikes on dslreports test over 5ghz WiFi.
PD: each environment/ISP is different so this may not work for you
Finally my more specific router arrived, the edgerouter x hoping to mitigate the very high latency so I decided to try openwrt, I installed sqm but when I did the tests
I get the same it seems that sqm does not work or I do not know what the problem is
Nor do I. How about we try to quantify the magnitude of latency you encounter in your games first?
Could you try to give some numbers here? Also how large is the typical best-case RTT to the game servers. Which game(s) are you playing in the first place?
And could you run something like sudo mtr -ezb4 -i 0.5 8.8.8.8 while you game and your uploads are running and copy & paste the output here in the forum (if done correctly this can help get a feeling where the latency actually is added to the packets)
OpenWrt (10.173.221.218) 2020-09-03T21:00:48+0000
@Not a TXT recordplay mode Restart statistics Order of fields quit
@Not a TXT record Packets Pings
Host @Not a TXT record Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply) @Not a TXT record
2. AS??? 10.150.148.33 (10.150.148.33) 0.0% 455 41.1 32.3 9.0 201.6 28.0
3. AS??? 10.95.153.249 (10.95.153.249) 0.0% 455 24.1 30.8 8.5 308.9 30.3
4. AS??? 10.95.153.242 (10.95.153.242) 0.0% 454 26.2 40.5 19.3 236.9 23.6
[MPLS: Lbl 9730 TC 0 S 1 TTL 1]
5. AS??? 10.95.156.34 (10.95.156.34) 0.0% 454 26.4 40.9 19.3 223.2 26.7
6. AS15169 209.85.173.137 (209.85.173.137) 0.0% 454 116.3 119.5 97.7 269.1 25.2
7. AS15169 108.170.253.17 (108.170.253.17) 0.0% 454 106.2 119.4 98.3 347.8 29.5
8. AS15169 209.85.248.243 (209.85.248.243) 0.2% 454 133.0 116.5 94.2 380.3 28.6
9. AS15169 dns.google (8.8.8.8) 0.0% 454 105.0 109.7 87.7 309.9 27.8
Here I did my result playing and sending a video via whatsapp and live classes
I play mostly Warzone
Supongo que tienes internet por ADSL, el modem del operador estĂĄ en modo bridge o tienes doble Nat poniendo tu router?
English: I guess you have ADSL, is the ISP modem in bridge mode or are you having double NAT?
PD: I speak both languages but spanish it's my native language
1 Like
si el router de mi ISP lo tengo en modo puente y todo el trabajo lo hace openwrt
Probaste el SQM que trae el firmware de Ubiquiti antes de ponerle OpenWRT?
Llevo 7 años sin tocar un internet ADSL pero creo que lo que se satura es tu upstream, prueba bajandole la velocidad
le bajo la velocidad a la descarga ? o subida
si pero no noto mejoras y solo tra fq_codel que al parecer mencionar que es algo viejo y no trae cake
1 Like
Haz el test de dslreports y båjale al que te dé mås ping