OpenSpeedTest as an Addon

[SomeWhereOverTheRainBow]

I've been using OpenSpeedTest for a while now. It's an excellent application. The tests perform better with a router or device with good processing power. It's necessary to have a good network cable, Cat6. Currently, I use SpeedTracker to generate a report, as complaints about bandwidth consumption follow criteria based on monthly averages. The link to SpeedTracker is: https://github.com/henrywhitaker3/Speedtest-Tracker

I tried it with a cat5e cable, which was fine as well. Like @rgnldo says it does depend on cpu as well. On our routers with QoS enabled, you are only going to see what the CPU will allow.

 

[rgnldo]

I tried it with a cat5e cable, which was fine as well. Like @rgnldo says it does depend on cpu as well. On our routers with QoS enabled, you are only going to see what the CPU will allow.

It works with Cat5e, but with a good shielded Cat6 cable, we'll get better results. Other factors that interfere or help include: a good NVME SSD, a WiFi 6 2x2 card, and a good CPU.

 

[vlord]

I made a tweak to my post here. It seems updating nginx will overwrite your default index.html. I've chmod index.html to remove write access and hopefully that should help.

 

[ColinTaylor]

I've chmod index.html to remove write access and hopefully that should help.

It won't. See similar issue here.

 

[vlord]

It won't. See similar issue here.

Ugh… I guess a better approach is to just have a backup of index.html and maybe script restoring it after an entware update.

 

[SomeWhereOverTheRainBow]

Ugh… I guess a better approach is to just have a backup of index.html and maybe script restoring it after an entware update.

Or make a different directory for your existing one and point your nginx.conf to use the new directory accordingly.

 

[vlord]

I finally got around to getting a 2.5G USB adapter for my Mac Mini to test OpenSpeedTest running on my AX-86U via 2.5G. After initially getting disappointing results, I followed @ColinTaylor suggestion in this post to resolve the kernel errors I was seeing:

kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed


Upon applying his fix, I am now seeing peaks above 2GB on read but on write they are a lot slower. I thought it might be my Samsung fit drive, so I temporarily move openspeedtest to the /tmp dir. This didn't seem to make much a difference. Also to note that the CPUs are quite loaded on the download and less so on upload. Here are some screen shots to share:

1. Representative download and upload. Increasing ?S=30 didn't make a huge difference. Neither did increasing or decreasing the worker loads.

2. Htop while running download and upload speedtest, respectively from Samsung Fit drive

 

[OpenSpeedTest]

@vlord Make sure you have installed the driver for the chipset on your Mac. When testing a 1Gbps USB Ethernet adapter that uses a Realtek chipset, I found that without drivers I got around 800 Mbps. After installing the driver, I achieved the full 1Gbps speed. You may also want to enable jumbo frames on your Mac for further optimization.

Use Chrome, Chromium or Safari

 

[vlord]

@vlord Make sure you have installed the driver for the chipset on your Mac. When testing a 1Gbps USB Ethernet adapter that uses a Realtek chipset, I found that without drivers I got around 800 Mbps. After installing the driver, I achieved the full 1Gbps speed. You may also want to enable jumbo frames on your Mac for further optimization.

Use Chrome, Chromium or Safari

It's definitely not the Mac Nic driver. This is Lan to Wan from my Mac mini:

 

[vlord]

@vlord Make sure you have installed the driver for the chipset on your Mac. When testing a 1Gbps USB Ethernet adapter that uses a Realtek chipset, I found that without drivers I got around 800 Mbps. After installing the driver, I achieved the full 1Gbps speed. You may also want to enable jumbo frames on your Mac for further optimization.

Use Chrome, Chromium or Safari

Also, I did try to disable rx-checksumming which is what helped with the dl speeds going above 1.2Gbit but I get an error doing so:

admin@RT-AX86U-AP2:/tmp/home/root# ethtool -K br0 rx off
Cannot change rx-checksumming

 

[ColinTaylor]

Also, I did try to disable rx-checksumming which is what helped with the dl speeds going above 1.2Gbit but I get an error doing so:

admin@RT-AX86U-AP2:/tmp/home/root# ethtool -K br0 rx off
Cannot change rx-checksumming

That's because it's already fixed off.

# ethtool -k br0 | grep rx-checksumming
rx-checksumming: off [fixed]

 

[elorimer]

One thing I'm a little curious about. When opkg installs nginx, it adds an S script but it doesn't follow the normal pattern of these scripts. It doesn't call rc.func, for example, and doesn't have "empty" pre and post commands and args. The cases it handles are start|stop|restart|reload|reopen|test instead of start|stop|restart|reconfigure|check|kill.

So, for example, if you call rc.unslung check you get a usage error instead of "alive".

 

[ColinTaylor]

One thing I'm a little curious about. When opkg installs nginx, it adds an S script but it doesn't follow the normal pattern of these scripts. It doesn't call rc.func, for example, and doesn't have "empty" pre and post commands and args. The cases it handles are start|stop|restart|reload|reopen|test instead of start|stop|restart|reconfigure|check|kill.

So, for example, if you call rc.unslung check you get a usage error instead of "alive".

The same is true for many other packages. I don't know whether there's any requirement for a package to follow the scripting format you describe, I doubt it. I'd always assumed it's just a template that's provided as a convenience rather than a mandatory standard.

 

[elorimer]

I think you are right, but it is odd that opkg would install an S* script that doesn't conform to the template. So if you run rc.unslung test all the other scripts will trigger usage errors.

 

[vlord]

So I upgraded my AP from an RT-AX86U to an RT-AX86U Pro. There is definitely more under the hood work going on than just the CPU upgrade. I think if you are looking to have a full on internal speedtest server running on your router, the BCM4912 is where it's at.

 

[vlord]

Hey all — I’m running OpenSpeedTest with NGINX directly on my Broadcom-based router (Asuswrt). During Speedtest downloads (i.e., when the router is serving data to a wired client), I’m seeing a major performance bottleneck over Ethernet.

The download speeds are much lower than expected, while upload speeds are unaffected. Watching htop, I noticed that the [bcmsw_rx] kernel thread is pegged at 100% on a single core (usually CPU0) during the download. This wasn’t the case before as noted above.

As mentioned previously, on that firmware release, I was able to hit full speed and could see all four CPU cores being utilized during heavy download traffic. Now, it looks like only one core is doing all the work — and that core gets saturated. This seems to be a new bottleneck, and I’m wondering if something changed at the kernel or driver level.

From what I understand, [bcmsw_rx] is responsible for handling RX packets from the Broadcom switch. Since it’s a kernel thread, its CPU usage doesn’t show under user-space processes like NGINX — which aligns with what I’m seeing.

Questions:

• Has anyone seen [bcmsw_rx] bottleneck like this during router TX?
• Could this be due to IRQ/core binding changes in the firmware?
• Any way to spread RX processing across multiple cores or tweak IRQ affinity?

Happy to provide logs or additional testing details if it helps. Appreciate any insights!

@ColinTaylor - I know this is an area of your expertise, so hoping you may have some insight as well.

Results:

htop:

top:

 

[Crimliar]

OMG are we all too "up our selves" to run iPerf any more?

 

[Twiglets]

OMG are we all too "up our selves" to run iPerf any more?

Not everybody knows what iperf is !!!