SQM doesn't do its job

So you installed the firmware image for a WR840Nv4 on your WR841HPv5 by using the force option? Or did you switch your router for an WR840Nv4?
Anyway, if you use a non-matching firmware image things might easily go wrong.
Please continue testing, and if you encouter the problem again with increased latency during whatsapp uploads, run the following command tc -s qdisc to check whether the sqm shaper is still instantiated and post its output here, thanks. And btw, I live on the other side of the world, so am on a different night/day cycle :0

si tiene razón, use la fuerza en la instalación o eso, quiero decir, ya que usé tftp para flashear openwrt

1 Like

Por eso es que no te esta funcionando bien. Tienes que usar una version compatible con tu dispositivo.
Aun la mas menor diferencia puede causar problemas. Por ejemplo, la perdida de la configuración que te paso.

ENG: that's why it is not working, you need to use a build specifically made for your hardware. Even the most minor variances can cause issues, such as losing your settings, as happened to you.

1 Like

I am with TopDog, and am very suspicious of the almost fitting firmware image to cause some issues.
Please try to just run this and collect the tc -s qdisc output the next time you encounter the latency issues. Make sure to collect the data as quickly as possible, and also collect the output of uptime please to see how long the router was running at that time.

P.S.: I like TopDog's style of adding an english translation immediately to a spanish/non-english text, as the forum's language is english, I wish I had thought about proposing that.

incluso si es el mismo hardware?

It is not the same hardware, as your linked thread showed, different RAM amount, different CPU speed, etc.

So do not even try. Please find a supported piece of hardware. I'm sure that with all the pandemic network upgrading going on, some people are selling off older, but well-supported hardware. For example an Archer C7 (TP-Link).

tenia el archer c7 v5 tuve que venderlo ya que no se acomodaba a mis necesidades con openwrt lo primero que notaba era que no me daba el plan contratado de mi isp era muy baja la velocidad de internet mal equipo

Mmmh, I am pretty sure I have seen results with Archer C7s reaching your bandwidth with SQM, so could it have been that your unit was defective?

Edwpat, I have a lot of experience with C7s (hundreds of units), and they are very good hardware, and can absolutely keep up with the speeds shown in your tests. The latest OpenWRT Wifi for them has a few issues, but as far as SQM, they work fine at less than 100Mbps.

recientemente entre a jugar entonces en media partida mi latencia se subio a 900ms entonces queria saber el porque pero no recorde que comando era para ver eso

root@OpenWrt:~# tc -s
Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
       tc [-force] -batch filename
where  OBJECT := { qdisc | class | filter | action | monitor | exec }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[aw] |
                    -j[son] | -p[retty] |
                    -b[atch] [filename] | -n[etns] name |
                    -nm | -nam[es] | { -cf | -conf } path }
root@OpenWrt:~# uptime
 02:33:58 up 2 days,  1:25,  load average: 0.00, 0.00, 0.00

aunque solo esto logre ejecutar cuando la latencia bajo

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

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.