Re: [beagleboard] Speedtest-cli headache on BB black
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. -- 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/4b752b9c-ed2f-4809-a182-77faeac219ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Speedtest-cli headache on BB black
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! -- 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/3791b479-6a4e-4caa-a8c5-6232bf876683%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Speedtest-cli headache on BB black
On Fri, Feb 9, 2018 at 8:42 AM, Robert Nelson wrote: > On Fri, Feb 9, 2018 at 5:00 AM, 'NetworkSorcerer' via BeagleBoard > 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 ()... > 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
Re: [beagleboard] Speedtest-cli headache on BB black
On Fri, Feb 9, 2018 at 5:00 AM, 'NetworkSorcerer' via BeagleBoard 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 ()... 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... Tes
