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 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.