Hi Folks
Boy this is a doozy…
I’ve been trying to set up a Beaglebone Black as a lightweight autonomous networking appliance to monitor and analyse connection performance at remote locations, the method is fairly straightforward. I’m using a simple bash script to run speedtest-cli and then pipe the output into an email with mailutils/ssmtp and to that end, everything performs flawlessly, except that the actual results from speedtest-cli are complete mince.
We’ve ruled out the basics at this point, iperf is showing the NIC is capable of transfer rates of around 90mbps on a 100mbps link which is optimal when one takes into account TCP overheads etc, we’ve run a few different incarnations of the same type of test under different languages such as C++ but to no avail, the device still reports erroneous results. We’ve tried running under a few different Kernels both old and more recent, we’ve tried running under python 2.7 and 3.1
Some example outputs (all wired on a 100/1000 syncronous fibre, uncomplicated flat network with <10 devices, 2 users):
From a debian VM on a Laptop with plenty of poke
root@test-VirtualBox:/etc/ssmtp# ./speedtest-cli --server 226
Retrieving speedtest.net configuration…
Testing from [insert ISP here] (xxx.xxx.xxx.xxx)…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by Structured Communications (London) [2.56 km]: 30.928 ms
Testing download speed…
Download: 31.86 Mbit/s
Testing upload speed…
Upload: 52.86 Mbit/s
This result, although not indicative of 100/1000 performance is considered optimal as such tests are not designed for synchronous services and often report silly results, the key factor is that it executed swiftly (10-15ish seconds) and is in line with what we would expect from running its online cousin in flash/html5.
Beagleboard output
debian@beaglebone:~/speedtest$ ./speedtest-cli
Retrieving speedtest.net configuration…
Testing from [insert ISP here] (xxx.xxx.xxx.xxx)…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by Cybersmart Pty Ltd (London) [2.56 km]: 2548.699 ms
Testing download speed…
Download: 3.18 Mbit/s
Testing upload speed…
Upload: 3.37 Mbit/s
The execution time on the beagleboard is on the order of a couple of minutes, with max CPU spikes being noted during the process, mostly from python. Take particular note of the ludicrous ping and strange Tx/Rx numbers. In mentioning pings too, we’ve noted that while reported latency from ICMP packets is nominal, again the execution is sluggish, running significantly slower than even the oldest most hacked up x86 box we have kicking about. Some discrepancy is expected due to the differing architectures but surely not so noticeable??
A network trace during the test shows no significant anomalies in packet transmission (too large to post) and we have reproduced the issue on a couple of units reducing the likelihood of it being a hardware fault, everything seems to point to some oddity in how the device is handling the job and we cant for the life of us put a finger on it.
Any insight from those who better understand the nuts and bolts of these wee beasties would be hugely appreciated, we can work around this by using iperf if we have to but would prefer to be able to deploy these as standalone units (iperf would require us to run a box on our end long term).
Current Kernel - 4.14.17-ti-r32