[BUG] Download speeds much slower than browser-based speedtest.net

[jefcorco]

I noticed that the download speed is much slower than if I just point a browser to speedtest.net. 100 Mbps vs. 500 Mbps. I'm running the pre-build docker image on top of Windows 10.

I thought that maybe the default servers in Settings (blank) might have been choosing distant servers, so I entered a server in my city with the same result.

I also thought that the docker network might be throttling packets. To test this I bought up iperf3 in a container on the same docker network and was able to get 500 Mbps throughput.

So not really a bug, but something unexplained. Getting accurate results would make this a really incredible tool.

[jiriteach]

You need to ensure that you are running this in host mode and not via a bridge - I get full speeds for my link which is a gig - I've been running it over ~ a year with accurate results.

[jefcorco]

@jiriteach That makes sense. I'm running docker on Windows 10 using the WSL 2 back-end. When I try to start the container on the host network, I can't reach any IP. I also tried installing natively on Windows 10 using hyper-V but same result. Looking at the documentation: https://docs.docker.com/network/host/, it appears that this is not supported:

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

[jiriteach]

Add -

network_mode: host

to your docker-compose.yml. I havent use Docker much on Windows sorry, I am running it on a Linux host.

[luk6173]

If changed also to host, but get this error:

[23-Aug-2022 06:41:53] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address in use (98)
[23-Aug-2022 06:41:53] ERROR: FPM initialization failed

What's wrong?

[michealespinola]

[23-Aug-2022 06:41:53] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address in use (98)

Something else is already using port 9000, so pick a different one

[bverkron]

I ran into the same issue with port 9000. Portainer was running on that port by default.

I tried changing the port that speedtest was running on via the docker-compose file by adding this to the ports section but it did not work, I assume since that's mapping the ingress and not what the container is string to setup to listen on?
- 8766:9000

Instead I changed the port Portainer was using but now I get this.
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)

Is there a way to configure which ports speedtest is using internally? I have other things running on port 80 on this docker host and my network in general I am not willing to change.

[bverkron]

Think I found it here in the mounted config directory. Will have to fiddle with this tomorrow:

/nginx/site-confs

server {
	listen 80 default_server;

	listen 443 ssl;

	root /config/www/public;
	index index.html index.htm index.php;

	server_name _;

	ssl_certificate /config/keys/cert.crt;
	ssl_certificate_key /config/keys/cert.key;

	client_max_body_size 0;

	location / {
		try_files $uri $uri/ /index.php?$args;
	}

	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		# With php5-cgi alone:
		fastcgi_pass 127.0.0.1:9000;
		# With php5-fpm:
		#fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;

	}
}

[michealespinola]

Port 80 is already going to be in use on a lot of devices, since its the default web port. It would be easier to just use another high-value registered port. Psuedo-standards would suggest that it should be in the 8000-8999 range, since its a web interface.

As an example, I have mine set to 8765

[jefcorco]

Running in host mode instead of bridge mode is reported to fix the slowness. However, the host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

[bverkron]

Port 80 is already going to be in use on a lot of devices, since its the default web port. It would be easier to just use another high-value registered port. Psuedo-standards would suggest that it should be in the 8000-8999 range, since its a web interface.

As an example, I have mine set to 8765

Yes I'm aware 80 is a very common port hence why I don't want to fiddle with my already running services to change it :)

I attempted to change it in the /nginx/site-confs/default file I referenced above and I re-built the container but it still throws the same error. Is that the wrong location to change it?

[michealespinola]

Sorry if I missed it above, but I'm guessing you're not using the docker version? I think issues #938 and #393 address how to handle the port in different ways. It's a bit out of my depth, so I can't give any advice, sorry.

[bverkron]

Found the issue. The nginx files got mixed around in the mounted volume location and it was pointing to a default config instead of the one I modified (don't ask, lol).

So, it's now running in host mode and nginx is set to use a different port instead of 80 (in this case 8888). But the test results are still the same, less then 100 Mbps, when I have Gigabit internet service and get 900+ Mbps on my laptop.

version: '3.6'
services:   
  speedtest:
      container_name: speedtest
      image: henrywhitaker3/speedtest-tracker
      # required to get full speed
      network_mode: host
      # not required when running in host mode as the ports are defined by the built in nginx instance in nginx/site-confs/default
      # ports:
      #  - 8765:80
      volumes:
          - /home/master/speedtest/mount_config:/config
      environment:
           - TZ=America/Vancouver
           - OOKLA_EULA_GDPR=true
      logging:
          driver: "json-file"
          options:
              max-file: "10"
              max-size: "200k"
      restart: unless-stopped   

nginx/site-confs/default

server {
        listen 8888 default_server;
... rest of file is defaults...
}

[bverkron]

Hmmm looks like I'm getting < 100 Mpbs on the host OS directly too. Must be something up with the configuration there. I'll have to troubleshoot the host. Sigh.

$ speedtest

   Speedtest by Ookla

      Server: ************
         ISP: *******
Idle Latency:     2.59 ms   (jitter: 0.70ms, low: 2.16ms, high: 3.25ms)
    Download:    93.85 Mbps (data used: 45.7 MB)                                                   
                 11.28 ms   (jitter: 13.16ms, low: 6.52ms, high: 241.44ms)
      Upload:    94.01 Mbps (data used: 43.4 MB)                                                   
                 12.56 ms   (jitter: 0.46ms, low: 11.68ms, high: 14.01ms)
 Packet Loss:     0.0%

[michealespinola]

Oof, that's pretty abysmal. I'm running it bridged in a container on my Synology NAS and I'm getting expected performance.

Are you consistently seeing Low-to-mid 90's? That strikes me as a 100 Mbps cap with overhead. Any chance you may have a 100 Mbps cap somewhere?

[alexjustesen]

Hey all, we're tracking this issue as well in the new repo as this project seems to be abandoned.

Follow along here: alexjustesen/speedtest-tracker#35

[bverkron]

Oof, that's pretty abysmal. I'm running it bridged in a container on my Synology NAS and I'm getting expected performance.

Are you consistently seeing Low-to-mid 90's? That strikes me as a 100 Mbps cap with overhead. Any chance you may have a 100 Mbps cap somewhere?

Found the culprit. Traced it back to a faulty ethernet cable that was feeding the main switch in my server room. The switch (and thus all connected devices) was running at 100 Mbps. There was a missing contact in the end. Never seen the before.

Replaced the end and getting closer to 1000 Mbps now on the host and in the container! Guess it was good this happened in the first place because it revealed a much bigger problem 😅

Host:

~$ speedtest

   Speedtest by Ookla

      Server: *****
         ISP: *****
Idle Latency:     1.98 ms   (jitter: 0.08ms, low: 1.85ms, high: 2.05ms)
    Download:   913.40 Mbps (data used: 1.3 GB)                                                   
                  4.96 ms   (jitter: 0.86ms, low: 1.47ms, high: 10.53ms)
      Upload:   900.51 Mbps (data used: 1.2 GB)                                                   
                  4.99 ms   (jitter: 1.25ms, low: 1.52ms, high: 11.40ms)
 Packet Loss:     0.0%

[alexjustesen]

@bverkron oooof, well the other issue still stands... CLI is slower in a Docker container so going to keep working at that.

[bverkron]

Thanks @alexjustesen I'll throw some (hopefully) relevant info into that other issue.

[michealespinola]

There was a missing contact in the end. Never seen the before.

@bverkron, I used to do a lot of network closet work, and would come across issues like this occasionally. Great work checking the physical cabling!

Interesting that it did indeed involve a bandwidth cap of 100mb somewhere in the chain as I suspected. I created and maintain a chart of expected bandwidths for various networking technologies (with network overheader reductions) for reasons exactly like this.

[bverkron]

Yeah it was pretty clear being around 100 Mbps that there was something misconfigured or a hardware issues like this. Way too coincidental to be anything else.

Admittedly I've only done a small number of cables in my home setup compared to a lot of people (maybe 50 ends or less?) so my sample size is pretty small 😅