On Fri, Feb 9, 2018 at 5:00 AM, 'NetworkSorcerer' via BeagleBoard
<beagleboard@googlegroups.com> wrote:
> 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

Smells like your switch/cable to the BBB:

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>)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
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>)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
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/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiGfb7ZHvCi4LAuT9-%2BqGfDOgiSaisTeRQaE1U3kiFzpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to