I promise you, but you know me, I love to find the solution myself 
at least did some simple testâs so i believe it isâŠ
# rpm -qa | grep speedtest
speedtest-cli-2.1.2-1.ns7.noarch
is this the expected output one the NethGUI?
Retrieving speedtest.net configuration...
Testing from KPN (145.132.93.22)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by KPN (Rotterdam) [18.72 km]: 13.035 ms
Testing download speed................................................................................
Download: 59.92 Mbit/s
Testing upload speed................................................................................................
Upload: 28.54 Mbit/s
and cockpit ?
2 Likes
I plane to add server.sponsor and server.id
1 Like
If you going to work on it, maybe put the units for Download/Upload in cockpit on the whiteboard too: MB /s instead of MB
2 Likes
I was the originator of this thread but hadnât weighed in since, but i am impressed and encouraged by the discussion. A few comments and a question:
Comments:
I think measuring speed (bandwidth) and round trip ping (latency) is a valuable diagnostic tool for Nethserver. In fact, if you could specify running it periodically and plotting the results, with a huge caution about not doing so often that it impacts total bandwidth limits many of the home broadband services have (in my case, 1.2 Terabits per month including the sum of upload and download) would be valuable. Being able to easily measure bandwidth and latency (defined in this case to be round trip ping) from NethServer provides a simple check on performance is valuable, because if you run tests from a desktop connected through a LAN or wireless LAN, and compare with tests from Nethserver, if Nethserver is directly connected to the gateway to the Internet (i.e. cable modem, DSL, fiber service, MPLS, SD-WAN, etc.), you can determine whether you have sub-par performance on the LAN/WLAN or if it is a service provider issue.
Almost all of the popular desktop and phone apps for speedtest show you a graph latency and jitter (variation in latency across a bunch of pings) and a graph or speedometer gauge for bandwidth. You guys might think about doing something simple, but it doesnât have to be fancy like the apps are. To use an expression popular in the United States, we arenât painting the ceiling on the Sistine Chapel here 
You guys probably all know that the service providers, unless you have some kind of leased-line business service, are all over-subscribing their infrastructure⊠The last time I talked to one of the service providers, in places it is 100:1. In other words, the actual cross-section capacity was 1/100 of the rated âbest effortsâ download speed summed across the number of customers on that slice of the infrastructure.
There can be a big difference in performance between TCP (which ACKs every frame) and UDP, particularly on asymmetric broadband connections which are common in the US. For example, my service (Comcast AKA Xfinity) is rated at 600Mbps download (from the Internet) and 15Mbps upload. When I ave measured it, the best case from my desktop was 550Mbps download, and 18Mbps upload. But often, especially during evening when people are streaming entertainment, it is 30+% slower.
I think that performance of maximum LAN bandwidth of Nethserver is sub-bar. The 550Mbps download speed, with about 12 milliseconds round trip latency, which was achieved with a Netgear R8500 WIFI router. The best I have ever seen measuring from my desktop with Netserver (running on an industrial fanless computer with a dual-core i7 4600U CPU and 8GB DRAM, and one Samsung SATA SSD, and built-in dual Realtek GbE ports, is 450Mbps, and if I look at the graphs of CPU utilization, it never gets close to 25% during speedtest. Comparing the CPUs, the Netgear is a dual-core Arm Cortex, 1.4GHz, and the Nethserver i7-4600U is a dual-core, base frequency of 2.1GHz, with a boosted frequency of 3.3GHz. The Intel CPU was designed for Ultrabook lightweight notebooks, and power efficiency, but my guess is that it should be, depending on task, 50% to 100% faster than the Arm processor.
It isnât a huge deal for me, but I would be interested to know what others see in performance.
Particularly with home or small business services in the US, the service providers adjust their network parameters to look good on Speedtest (the most common being Speedtest.net), but there are more sophisticated but still relatively simple ways to run tests that look at things like web page loading times that are actually more relevant. Would you guys be interested in some input on what might be useful? I have a colleague that knows a lot about this stuff.
1 Like
Thank you @stephdl: now itâs easier to reuse the button! 
But Iâm not sure about the new labels inside the popover. Iâm copying here what I have commented to the PR:
In my opinion, both âServer sponsorâ and âServer IDâ doesnât really offer a real value to the normal user.
What is the user supposed to do with them? The user should now the command line cli syntax to have relevant information from it.
If we want to expose extra info, it should be hidden by default.
1 Like
Just a matter to remove them, at least we could add more information because we could even have the external public IP of the server, what isp provider you are using using, the distance between you and the serverâŠobviously some of this are provided with the new version of speedtest-cli
1 Like
I think that also these info can be usefull. We can even show the full json somewhere, the important point is that such less relevant info should be hidden by default.
hum we are in a popover so yes we have to be short in information. I propose to make a speedtest tool in the network panel, we are in a modal, it is easy to play with any json output you need. no hurry to do it.
To solve this thread I would like to update speedtest and make the button reload workable
hello @mark_nl can you please give the ownership of the github repository of speedtest-cli spec file we would like to build and push it to our repo ?
I agree 
1 Like
If Iâm not mistaken it is already yours @stephdl
1 Like
yep but I saw you did one more commit, do we have to cherrypick ?
You may want to merge branch el7 into master and remove some Fedora build-system bits (.gitignore and sources)
It is a clone / fork from here:
Hello everybody,
I just would add my 2 cents to this topic especially about the fact that NethServerâs speedtest can be sub-bar.
This can actually be true if you have some broadband connection with some hundreds of Mbps, because the speedtest process on nethserver itself uses CPU in not negligible way.
I had the opportunity to check this in various cases and it is more evident when there are many services that are running.
On the other hand an i7 4600U CPU can still work very well, but its performances are quite far from mor recent CPUs.
About ARM Cortex itâs difficult to make a compare cause they have a completely different architecture.
1 Like
transfered to NethServer, thank mark
@giacomo could you accept the repository
2 Likes
No further action is required, the repo is already there: https://github.com/NethServer/SPEC-speedtest-cli
Youâre now the admin
1 Like
HERE WE ARE
2 Likes
A clarification on my comments about the i74600U processor and Arm. You are correct, the i74600U is an older CPU, it was designed for low power ultrabooks, so it isnât anywhere near as fast as a modern one, and definitely not as fast as a current Xeon. Having said that, for a single threaded process like the Nethserver speedtest (I am making a guess that it only uses one core for the main processing loop), often the memory bandwidth is on the critical path. The reason is that since you only touch a data item once, the cache isnât of as much help as if it were operating on a higher locality of reference data set. Further, it is integer operations, and since it is one thread, one core, then the multi-stage pipeline stuff that higher end server processors have doesnât help. Further, with the slowdown of Mooreâs Law, a 5 year-old CPU isnât as slow compared to a current one as it used to be, and much of Intelâs focus has been on improving battery life, not raw speed.
Concerning my comments on Arm, I have been spending a fair amount of time looking at Arm A7 (Cortex) processor performance versus Xeon for networking applications (Open vSwitch, firewall, routing, VPNs), Contemporary Xeons have seperate multi-level on-chip caches per core, and the Cortex processor always (I think) has one cache per pair of cores. With similar clock rates, for benchmarks that are helped by the cache, the ratio is about 2:1. As a conservative example, in our testing, a 3Ghz Arm using a single IPsec VPN connection in a VM using virtio, with 25GbE server class Ethernet NICs, no DPDK, no optimizations, can achieve in excess of 1 Gb/sec on 1 core for the VPN and 1 core for the kernel.
Where I mispoke, is that the Arm Cortex performance is probably closer to the i7 4600U, since the 4600U processor is not as fast as Xeon for even simple single-thread applications.