NetworkSorcerer
Feb 9, 2018, 7:32:30 AM2/9/18
to BeagleBoard
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
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
Robert Nelson
Feb 9, 2018, 9:43:37 AM2/9/18
to Beagle Board
This BBB: is connected to a 10/100 switch <-> 10/100/1000 switch <->
router <-> 1000 / 20 Cable
debian@bborg-stretch-v8-18:~$ uname -r
4.14.16-ti-r30
debian@bborg-stretch-v8-18:~$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Midcontinent Communications (<ip>)...
Hosted by Midco (Grand Forks, ND) [10.60 km]: 17.254 ms
Testing download
speed................................................................................
Download: 86.16 Mbit/s
Testing upload speed....................................................................................................
Upload: 20.83 Mbit/s
on an x86 host, connected to the 10/100/1000 switch:
voodoo@nuc-git:~$ uname -r
4.9.0-5-amd64
(Qualcomm Atheros AR816x/AR817x Ethernet) (had better when it was a
intel nuc with intel e1000)
voodoo@nuc-git:~$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Midcontinent Communications (<ip>)...
Hosted by Midco (Fargo, ND) [113.89 km]: 11.954 ms
Testing download
speed................................................................................
Download: 766.46 Mbit/s
Testing upload speed....................................................................................................
Upload: 20.98 Mbit/s
Regards,
--
Robert Nelson
https://rcn-ee.com/
Robert Nelson
Feb 9, 2018, 9:45:48 AM2/9/18
to Beagle Board
more apples/apples..
Retrieving speedtest.net configuration...
Testing from Midcontinent Communications (<ip>)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Testing download
speed................................................................................
Download: 625.15 Mbit/s
Testing upload speed....................................................................................................
Upload: 20.86 Mbit/s
(the fargo office is better in our area, even thou it's 100Km away)
Regards,
Robert Nelson
https://rcn-ee.com/
GelginX
Feb 9, 2018, 12:03:43 PM2/9/18
to BeagleBoard
That's darned curious to be sure. Cabling issues were looked at early, first we though it was piping through the usb, then we hooked up directly to our gateway (a draytek vigor... notoriously glitchy routers imo) to eliminate any dodgy structured cabling or switching gear.
Boss is going to take it home over the weekend and plug it into his home network and try it out over entirely different hardware over a vDSL to see if any difference can be spotted.
Many thanks for giving yours a whirl and posting the output, it gives hope where it was once fading fast!
Boss is going to take it home over the weekend and plug it into his home network and try it out over entirely different hardware over a vDSL to see if any difference can be spotted.
Many thanks for giving yours a whirl and posting the output, it gives hope where it was once fading fast!
GelginX
Feb 12, 2018, 4:54:25 AM2/12/18
to BeagleBoard
Just for the interest of anyone reading, the issue appears to have been isolated to either the syncronous line or the Draytek Vigor. The over weekend test on a vDSL with an ASUS router returned a useful and sensible result without issue or fuss so fairly confident of the source, readers beware, Drayteks are a false economy!
This will not be the first time I have seen a problem attributed to the presence of a Draytek (they are notorious for causing trouble with VOIP services) and consequently is being removed, burnt and replaced with something else.
This will not be the first time I have seen a problem attributed to the presence of a Draytek (they are notorious for causing trouble with VOIP services) and consequently is being removed, burnt and replaced with something else.
Reply all
Reply to author
Forward
0 new messages