I've just tried downgrading to 23.05.3, then opkg upgrading all packages.
Bufferbloat test shows better speed, though still far from desired:
https://www.waveform.com/tools/bufferbloat?test-id=488e2ce0-f37b-4777-989f-b5bb7e690e18
1 Like
What is the link speed seen on client and in bottom of luci status page under tests
Summary
During download phase:
During upload phase:
And the result:
https://www.waveform.com/tools/bufferbloat?test-id=76e3d078-5c66-4929-96bc-8d2f52ece3b5
Tx rate and bitrate actually go down, compared to all clients idling.
Are antennas parallel to eachother?
Somewhat. Thought they were all pointing horizontally.
I tried pivoting all of them towards the ceiling and that gave me 20~ish more mbps download speed and increased peak bitrate during download phase to over 660.
Honestly, I did not realize antenna orientation would make that much difference.
Edit: here's how it looks now
The zone is donut-shaped around antenna, and for beamforming 2 zones should overlap.
Still not to the spec, should be 400/400 with maybe latency if link speed indicated is 866 (in practice a bit above half of advertised can be reached)
Okay, so here's another confusing thing.
https://www.waveform.com/tools/bufferbloat?test-id=0c7dfde4-d943-4ea1-b52b-5844b0793d50
This is the same test, on the same SSID, in the same place as the PC.
Except I ran it on my Pixel 7A.
edit:
And here's an Asus Vivobook with RTL8821CE wireless, on the exact same desk.
https://www.waveform.com/tools/bufferbloat?test-id=027953c1-eb38-44d6-a414-9b06345e5083
edit2:
And the PC (has an Intel AC 7265 pci-e network card), after reorienting router's antennae:
https://www.waveform.com/tools/bufferbloat?test-id=ca907fb2-f70d-4307-b140-5d1fa07f9552
Just what is going on here?
Now check ethtool -S wan -> any pause employed?
Doesn't look like it?
root@OpenWrt:~# ethtool -S wan
NIC statistics:
tx_bytes: 8531554136
tx_packets: 8277863
tx_skip: 0
tx_collisions: 0
rx_bytes: 8170043341
rx_packets: 7264188
rx_overflow: 0
rx_fcs_errors: 0
rx_short_errors: 0
rx_long_errors: 0
rx_checksum_errors: 0
rx_flow_control_packets: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
Also, my favourite bandwidth test of trying to torrent a recent episode of a popular TV show shows that current download speed is at about half of what OEM firmware could deliver. But half is way better than 1/10th, which is what initially caused me to notice this whole issue.
Edit:
I've ran into a limit of new messages per day for new forum users.
@brada4 Re: ethtool -A
root@OpenWrt:~# ethtool -A wan tx off rx off autoneg on
Cannot get device pause settings: Not supported
Interestingly enough ethtool -a does work for LAN ports.
IF ethtool -a/-A works do:
ethtool -A tx off rx off autoneg on wan
ethtool -r wan
ethtool -a wan
(pause was off in ethtool wan but one in million device combinations do get something wrong)
Another test would be iperf3 on the device itself, it will not reach great speeds, but should be symmetrical both ways.
1 Like
To be clear, everything past this message
is on 23.05.3.
1 Like
But this shouldn't affect wired connection, right?
I was in a google meet call today, on wired connection, and had some connection issues.
Decided to run a quick bufferbloat test and got some terrible upload results: https://www.waveform.com/tools/bufferbloat?test-id=955d75f9-48a4-4dd2-85a0-6fce1e299cf3
It is the provider then. nothing you can do
Not sure about that, running a speedtest on the router gave the expected results of 300+ mbps in both directions.
Honestly, I am tempted to just get a new router at this point.
Strange. Nice if you can borrow similar or better router. Might be freshly planted network filters hurt your providers infra. ymmv.
Here's an update: it actually got even worse just by itself over time.
This is that same Asus laptop from before, sitting on the same desk from before.
https://www.waveform.com/tools/bufferbloat?test-id=efd80aaf-5af7-4708-951d-3a14a93f11f4
Edit: update to the update
I've restarted the radio (using the 'Restart' button on the wireless tab in luci), it selected a different channel (was 52, now 132) and bufferbloat test now looks like this:
https://www.waveform.com/tools/bufferbloat?test-id=294da879-ae7c-4e08-9576-f88917267ed2
Which in summary is very bad and unlikely, somebody with similar or same device either needs to confirm either massive SW regression or some electrical damage.