spdMerlin spdMerlin - v4.x - speedtest and bandwidth monitoring

Jack Yaz

Part of the Furniture
v4.4.4
Updated 2022-01-16


spdMerlin is an internet speedtest and monitoring tool for AsusWRT Merlin with charts for daily, weekly and monthly summaries. It tracks download/upload bandwidth as well as latency, jitter and packet loss.

spdMerlin is free to use under the GNU General Public License version 3 (GPL 3.0).

spdMerlin uses Speedtest CLI

spdMerlin includes the required licenses, which must be accepted on install of spdMerlin.
As of spdMerlin v4.4.0 the Asus built-in Ookla speedtest binary is used to run the speedtests.

This script began as a user-friendly installer for a personal project developed by JGrana

A swap file is required.

This project is hosted on GitHub

Love the script and want to support future development? Any and all donations gratefully received!
PayPal donation

Supported firmware versions
You must be running firmware Merlin 384.15/384.13_4 or Fork 43E5 (or later) Asuswrt-Merlin

Installation
Using your preferred SSH client/terminal, copy and paste the following command, then press Enter:
Code:
/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/jackyaz/spdMerlin/master/spdmerlin.sh" -o "/jffs/scripts/spdmerlin" && chmod 0755 /jffs/scripts/spdmerlin && /jffs/scripts/spdmerlin install

Usage
WebUI

spdMerlin can be configured via the WebUI, in the Addons section.

Command Line
To launch the spdMerlin menu after installation, use:
Code:
spdmerlin

If this does not work, you will need to use the full path:
Code:
/jffs/scripts/spdmerlin
 
Last edited:

Jack Yaz

Part of the Furniture
Screenshots
 

Jack Yaz

Part of the Furniture
Since I don't have the usual testing time available, I'm going to gratefully ask the community for any willing beta testers. I have updated spdmerlin to v4.4.2 on develop, which you can test by running
Code:
spdmerlin develop
If anyone is willing to test, please let me know if you encounter any issues


Changes include:
Code:
Add option to toggle between speedtest binaries
Disable Result URL radios if using built-in binary
Use shortform -p instead of --progress (Fix arg parsing in latest ookla built-in in alpha firmware)
This also bundles an upgrade of the non built-in speedtest:
Code:
Update external speedtest-cli to 1.1.1

## Release Notes

### 1.1.1 - 11/15/2021
* Fixed issue with reported client version in uploaded results

### 1.1.0 - 10/27/2021
* Use server-side upload measurements
* Performance enhancement on upload tests for CPU constrained devices
* Security enhancements
* Fix for deadlock bug
* Fix crash due to race condition
* Fix crash in hostname resolution during test initialization
* Fix potential buffer overflow
* Update Boost to 1.77.0
* Update mbedTLS to 2.27.0
* Update cURL to 7.78.0
 

JGrana

Very Senior Member
Hi Jack, welcome back!

I have loaded 4.4.2 on an AX88U running 386.4 alpha1

On the cli, I ran a few speed tests using external and internal. Both ran fine (expected results) and showed the progress graph correctly.
On the WebUI, did the same. Both internal and external show expected results and correct progress chart.
I also checked after ~30 mins and the auto charts are updated fine.
Side note - for the manual runs, I tried both preferred server and Auto-select. My preferred has been RIT (local college) since it always showed correct results. Lo and behold, Auto-select always selects University of Rochester - very low ping time, but in the past seemed to cap download speeds.
Now, UofR is showing expected speed. Must have done something to their speedtest server.
I’ve changed Automatic mode to Auto-select for now.

Overall, looks good!
 

visortgw

Very Senior Member
@Jack Yaz I updated to the new beta on both an RT-AX86U (running 384.4 alpha2) and an RT-AC86U (running 384.4 alpha3) — I had previously been running the earlier 4.4.2 development branch build on both. The built-in binary once again works correctly. In limited testing, it appears that the built-in binary results in slightly higher (~10%) bandwidth results than the external binary. Thanks again for all of your efforts.
 

Sebastienbo

Occasional Visitor
Jack,

Thank you for your development, I love the spd module
I do have 1 suggestion, the speed currently is limited to +-400mbit download because the asus routers are going at 100% and can therfore not test higher speeds (even on my gt-ax11000) gaming router.
This mostly has as reason that the speedttest cli is a single core process.
However there could be a workarround:
Spawn 2 speedtest-cli's by forking them as processes, wait untill both processes have their result and then add them up.

For example if I have a line of 200mbit and spawn two processes then both will say I have 100Mbit download, so if we count them up we see 200mbit.
The threads will each fall into another cpu automatically (os does that)

With two processes we could measure speeds up to +-800mbit

If forking or threading is not possible in your programming language, you could also just run de cli's in background like this

speedtest-cli & > result_wan_thread1.txt
speedtest-cli & > result_wan_thread2.txt

with a loop you check if both files have the result, and then add the results up

This project does this already:
 
Last edited:

Jack Yaz

Part of the Furniture
Jack,

Thank you for your development, I love the spd module
I do have 1 suggestion, the speed currently is limited to +-400mbit download because the asus routers are going at 100% and can therfore not test higher speeds (even on my gt-ax11000) gaming router.
This mostly has as reason that the speedttest cli is a single core process.
However there could be a workarround:
Spawn 2 speedtest-cli's by forking them as processes, wait untill both processes have their result and then add them up.

For example if I have a line of 200mbit and spawn two processes then both will say I have 100Mbit download, so if we count them up we see 200mbit.
The threads will each fall into another cpu automatically (os does that)

With two processes we could measure speeds up to +-800mbit
you're assuming that each process would take 50% of the bandwidth. this will not result in accurate results at all
If forking or threading is not possible in your programming language, you could also just run de cli's in background like this

speedtest-cli & > result_wan_thread1.txt
speedtest-cli & > result_wan_thread2.txt

with a loop you check if both files have the result, and then add the results up

This project does this already:
if you're referring to the
--single
Only use a single connection instead of multiple. This simulates a typical file transfer.

that is not using cores, rather connections. again, this won't "boost" the result.

FWIW spdmerlin originally used that python based tool for speedtests, but would regularly CRASH routers due to excessive memory usage.
 

dev_null

Senior Member
Jack, using the stable version because I just switched providers and want to get a feel for their offerings over time.

Since you've constructed the email portions of connmon, might you consider adding a daily or weekly email summarizing the speed test results?

(You know from our work on dn-vnstat that I'm a big fan of having data pushed. I tried to figure out if I could export a report automatically and then grab that with our Diversion-based approach, but couldn't find the output file.)

EDIT: found the output file /opt/share/spdmerlin.d/lastx_WAN.csv but still my suggestion stands. :)

EDIT 2: if anyone is interested in doing the same in the meantime, load the div-email.sh (this pulls the email credentials from Diversion) from the vnStat-on-Merlin R1 scripts, then create a cronjob like this (this one emails the WAN output file at 23.59 on the days I run my speed tests):

cru a Speedmerlin-stats "59 23 * * 0,2,4 /jffs/scripts/div-email.sh Speedmerlin-stats /opt/share/spdmerlin.d/lastx_WAN.csv".

Note: no conversion, just reads the csv file as plaintext and embeds it in an email (so the time is in *nix format), but I only want to see that the speeds are all more or less what I'm expecting, so it's fit-for-my-purpose.
 
Last edited:

dev_null

Senior Member
And maybe one more thing to think about if you do notifications: an email if the speedtest results are lower than X (say, a percentage of either a specified number, or lower than the recent average/mean)?
 

Jack Yaz

Part of the Furniture
Jack, using the stable version because I just switched providers and want to get a feel for their offerings over time.

Since you've constructed the email portions of connmon, might you consider adding a daily or weekly email summarizing the speed test results?

(You know from our work on dn-vnstat that I'm a big fan of having data pushed. I tried to figure out if I could export a report automatically and then grab that with our Diversion-based approach, but couldn't find the output file.)

EDIT: found the output file /opt/share/spdmerlin.d/lastx_WAN.csv but still my suggestion stands. :)

EDIT 2: if anyone is interested in doing the same in the meantime, load the div-email.sh (this pulls the email credentials from Diversion) from the vnStat-on-Merlin R1 scripts, then create a cronjob like this (this one emails the WAN output file at 23.59 on the days I run my speed tests):

cru a Speedmerlin-stats "59 23 * * 0,2,4 /jffs/scripts/div-email.sh Speedmerlin-stats /opt/share/spdmerlin.d/lastx_WAN.csv".

Note: no conversion, just reads the csv file as plaintext and embeds it in an email (so the time is in *nix format), but I only want to see that the speeds are all more or less what I'm expecting, so it's fit-for-my-purpose.
connmon's full notification suite will be ported to all of my applicable scripts in time, though I admit I've been considering moving to pfsense on a custom built box that can keep up with my gigabit connection and run the QoS and IDS I desire
 

Jack Yaz

Part of the Furniture
v4.4.2 is now available

Changelog:

  • NEW: Add option to toggle between speedtest binaries
  • CHANGED: Disable Result URL radios if using built-in binary
  • FIXED: Use shortform -p instead of --progress (Fix arg parsing in latest ookla built-in in alpha firmware)
  • NEW: This also bundles an upgrade of the non built-in speedtest to 1.1.1 (release notes below)
    Code:
    11/15/2021
    * Fixed issue with reported client version in uploaded results
    
    1.1.0 - 10/27/2021
    * Use server-side upload measurements
    * Performance enhancement on upload tests for CPU constrained devices
    * Security enhancements
    * Fix for deadlock bug
    * Fix crash due to race condition
    * Fix crash in hostname resolution during test initialization
    * Fix potential buffer overflow
    * Update Boost to 1.77.0
    * Update mbedTLS to 2.27.0
    * Update cURL to 7.78.0
 

dev_null

Senior Member
...though I admit I've been considering moving to pfsense on a custom built box that can keep up with my gigabit connection and run the QoS and IDS I desire...
Please don't leave us behind! :eek:

Seriously, I've toyed with the same but I'm having too much fun seeing how far we can extend a consumer-based device!
 

Jack Yaz

Part of the Furniture
Please don't leave us behind! :eek:

Seriously, I've toyed with the same but I'm having too much fun seeing how far we can extend a consumer-based device!
at the very least i'd like to upgrade to an AX86U but they're £250 over here, and my "dream" pfsense build is £500-600 and would be a lot more powerful
 

dev_null

Senior Member
at the very least i'd like to upgrade to an AX86U but they're £250 over here, and my "dream" pfsense build is £500-600 and would be a lot more powerful
I am very pleased with my RT-AX86U, just about a year into ownership. But yeah, with the chip shortage prices never came down the way they usually do.

I lucked out because I found a gift card from some holiday or birthday which helped...
 

JGrana

Very Senior Member
New @Jack Yaz Donation thread - chip in to help buy Jack an AX86U?
:)
 

Sebastienbo

Occasional Visitor
you're assuming that each process would take 50% of the bandwidth. this will not result in accurate results at all

if you're referring to the
--single
Only use a single connection instead of multiple. This simulates a typical file transfer.

that is not using cores, rather connections. again, this won't "boost" the result.

FWIW spdmerlin originally used that python based tool for speedtests, but would regularly CRASH routers due to excessive memory usage.
Jack thank you for your response.

I've been in contact with ookla to understand where the problem might lay for only using 1 cpu core on the asus routers.

There answer was that it shouldn't, the binaries should allow multiple cores to be used. They think it might have to do with or the environment (kernel limits processes to one core ->to discuss with merlin OR it might be an implementation restriction

This is the response from the ookla developers:
From Ookla Support <[email protected]>
I have confirmed with our CLI devs that the speedtest CLI client is capable of utilizing multiple cores/threads provided the environment it is being run in isn't limiting it. On the surface (looking at the GitHub for this package) it appears to be our standard arm speedtest CLI package so I would suggest circling back to Merlin or the owner of the repo (Jackyaz) to see how they are implementing this. A quick check of our default speedtest CLI config shows it defaults to 4 cores typically and can increase if needed but it's possible the Merlin firmware could be forcing the app to only 1 core or something else in the environment may be doing that.

So it looks like we might find the rootcause and make run the speedtest at full capacity
 

Jack Yaz

Part of the Furniture
Jack thank you for your response.

I've been in contact with ookla to understand where the problem might lay for only using 1 cpu core on the asus routers.

There answer was that it shouldn't, the binaries should allow multiple cores to be used. They think it might have to do with or the environment (kernel limits processes to one core ->to discuss with merlin OR it might be an implementation restriction

This is the response from the ookla developers:

I have confirmed with our CLI devs that the speedtest CLI client is capable of utilizing multiple cores/threads provided the environment it is being run in isn't limiting it. On the surface (looking at the GitHub for this package) it appears to be our standard arm speedtest CLI package so I would suggest circling back to Merlin or the owner of the repo (Jackyaz) to see how they are implementing this. A quick check of our default speedtest CLI config shows it defaults to 4 cores typically and can increase if needed but it's possible the Merlin firmware could be forcing the app to only 1 core or something else in the environment may be doing that.

So it looks like we might find the rootcause and make run the speedtest at full capacity
for the ookla binary that's available to download, its typically invoked by:
Code:
/jffs/addons/spdmerlin.d/ookla/speedtest --interface="$IFACE" --format="human-readable" --unit="Mbps"
where IFACE is eth0,tun11 and so on

The help output doesn't suggest one way or the other that core configuration is an option
Code:
[email protected]:/tmp/home/root# /jffs/addons/spdmerlin.d/ookla/speedtest -h
Speedtest by Ookla is the official command line client for testing the speed and performance of your internet connection.

Version: speedtest 1.1.1.28

Usage: speedtest [<options>]
  -h, --help                        Print usage information
  -V, --version                     Print version number
  -L, --servers                     List nearest servers
  -s, --server-id=#                 Specify a server from the server list using its id
  -I, --interface=ARG               Attempt to bind to the specified interface when connecting to servers
  -i, --ip=ARG                      Attempt to bind to the specified IP address when connecting to servers
  -o, --host=ARG                    Specify a server, from the server list, using its host's fully qualified domain name
  -p, --progress=yes|no             Enable or disable progress bar (Note: only available for 'human-readable'
                                    or 'json' and defaults to yes when interactive)
  -P, --precision=#                 Number of decimals to use (0-8, default=2)
  -f, --format=ARG                  Output format (see below for valid formats)
      --progress-update-interval=#  Progress update interval (100-1000 milliseconds)
  -u, --unit[=ARG]                  Output unit for displaying speeds (Note: this is only applicable
                                    for ‘human-readable’ output format and the default unit is Mbps)
  -a                                Shortcut for [-u auto-decimal-bits]
  -A                                Shortcut for [-u auto-decimal-bytes]
  -b                                Shortcut for [-u auto-binary-bits]
  -B                                Shortcut for [-u auto-binary-bytes]
      --selection-details           Show server selection details
      --ca-certificate=ARG          CA Certificate bundle path
  -v                                Logging verbosity. Specify multiple times for higher verbosity
      --output-header               Show output header for CSV and TSV formats

I know nothing about kernel limits, that's a question for @RMerlin to help us out with (please :) )!


the built-in ookla binary on the other hand, mentions
Code:
threadnum = "8"
packetlength = "32000000"
in its config, but i must admit i don't see much difference between the built-in ookla at /usr/sbin/ookla and the /jffs/addons/spdmerlin.d/ookla/speedtest when run against the same servers
 

heysoundude

Part of the Furniture
New @Jack Yaz Donation thread - chip in to help buy Jack an AX86U?
:)
I think I tried this somewhere before...and it amounted to this. lol

How about seeing if @RMerlin can arrange a group buy discount directly with Asus? we'd probably need at least 20-50 people to sign up for something like this to make it worth Asus' while, and we may be limited to router model, IE RT-AX86-U only...
It may be easier for one of us to become an Asus dealer and use Direct messages here for discount codes...
Regardless, chip shortages and shipping delays are making obtaining things difficult from suppliers to manufacturers...
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top