You are not logged in.

#1 2022-09-09 23:19:26

anomaly
Member
Registered: 2022-09-09
Posts: 4

connection is faster on speedtest than actual downloads

i have around 350mbps and i can only use around 100mbps on pacman, firefox, whatever that stores the file on my hard drive

this is my speedtest-cli output

Testing download speed.
Download: 319.59 Mbit/s
Testing upload speed.
Upload: 33.89 Mbit/s

when i try to download something on /dev/null it uses my full speed

wget -O /dev/null http://cachefly.cachefly.net/100mb.test
--2022-09-09 20:13:07--  http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 204.93.142.142
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|204.93.142.142|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null                     100%[==============================================>] 100.00M  45.6MB/s    in 2.2s    

2022-09-09 20:13:10 (45.6 MB/s) - ‘/dev/null’ saved [104857600/104857600]

when trying to download something it's limited to ~14MB/s

wget http://speed.hetzner.de/10GB.bin
--2022-09-09 20:16:19--  http://speed.hetzner.de/10GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/octet-stream]
Saving to: ‘10GB.bin’

10GB.bin                        1%[                                               ] 123.60M  13.7MB/s    eta 14m 6s

my ifconfig

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255
        ether b4:2e:99:ed:7a:5c  txqueuelen 1000  (Ethernet)
        RX packets 758083  bytes 1111742287 (1.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 178810  bytes 57047298 (54.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xf7f00000-f7f20000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

if you want me to share more information about my system i'll do it, just ask for it, thanks

Last edited by anomaly (2022-09-09 23:22:21)

Offline

#2 2022-09-09 23:42:00

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: connection is faster on speedtest than actual downloads

What type and how fast is the device you are writing to?
https://wiki.archlinux.org/title/Benchmarking#dd

Do you get a similar result if you try the same file with both commands instead of using a different file for each?


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#3 2022-09-09 23:45:49

anomaly
Member
Registered: 2022-09-09
Posts: 4

Re: connection is faster on speedtest than actual downloads

Slithery wrote:

What type and how fast is the device you are writing to?
https://wiki.archlinux.org/title/Benchmarking#dd

thanks for your reply, it's a 1 TB HDD

sudo dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.78022 s, 186 MB/s

referring to your other question

wget -O /dev/null http://speed.hetzner.de/10GB.bin
--2022-09-09 20:50:53--  http://speed.hetzner.de/10GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null                       1%[                                               ] 120.18M  13.7MB/s    eta 14m 16s
wget http://speed.hetzner.de/10GB.bin
--2022-09-09 20:51:45--  http://speed.hetzner.de/10GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/octet-stream]
Saving to: ‘10GB.bin.1’

10GB.bin.1                      1%[                                               ] 128.60M  13.9MB/s    eta 14m 9s

Last edited by anomaly (2022-09-09 23:52:07)

Offline

#4 2022-09-10 07:21:22

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 74,314

Re: connection is faster on speedtest than actual downloads

From: "Arch Linux Forums Mailer"
To: seth
Subject: i really need your help
Date: Sat, 10 Sep 2022 01:50:50 UTC

anomaly from Arch Linux Forums has sent you a message. You can reply to anomaly by replying to this email.

The message reads as follows:
-----------------------------------------------------------------------

https://bbs.archlinux.org/viewtopic.php?id=279587

i'm sorry for sending this through here, i'm desperate for a solution

-----------------------------------------------------------------------

--
Arch Linux Forums Mailer

Srsly?

No matter how desperate you are because hetzner only serves you at 100Mbit/s: private mails in the middle of the night will neither draw my immediate attention (because I'm regenerating in my sarc… "sleeping") nor change anything about you not getting faster supply from random servers on the internet.
They might be under load or sport a quota or the peering agreement into your network segment includes a speed limit or whatnot, but your test in #3 (before you figured to just send mails in "desperation") clearly show that the destination is irrelevant and the limiting factor is the specific source.

For pacman choose faster mirrors, https://archlinux.org/packages/community/any/reflector/
For downloading porn with your webbrowser, I'm sorry but you'll simply have to exercise patience - no matter how hard yo… it is.

Offline

#5 2022-09-10 11:05:22

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 696

Re: connection is faster on speedtest than actual downloads

The internet is not an uniform thing, regardless if your ISP provides X speed, its just the theoretical top.

In practice my personal experience with whatever is ~60% on a busy time, but I'm sure Xfiniblegh is doing nonsense on their end and I'm stranded here in the land of the fee with bs options for ISP providers.
You could go on a rant of how diverse it is in reality, including IPv6 shenanigans for maximum rant potential as well.


My reposSome snippets

Heisenberg might have been here.

Offline

#6 2022-09-10 14:16:58

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,612

Re: connection is faster on speedtest than actual downloads

Yeah, perhaps this is a good time to remind everyone that proper etiquette does *not* include sending unsolicited support requests to personal email accounts..   That is way over the line.

A few comments on the OP's problem.

First, 14MB/s is on the order of 140Mb/s (8 bit bytes and some overhead), so the speed really is not grotesquely low.  It is in the correct order of magnitude for the channel bandwidth.

Second, there is zero guarantee that the host site is going to provide you with a 300Mb/s channel; they may only have 150Mb/s; they could rate limit individual requests -- you have no way to know.

Third, I have a hunch that speed tests use a whole bunch of many UDP packets in an effort to flood the channel to its full capacity.  UDP packets are fire and forget; there is no acknowledgment to the sender that they have been received.  For the speed tests, the client just totals up how many packets are received in a given time frame to determine the bandwidth.   When you download a file from a site, they are probably using TCP packets.  These have guaranteed delivery and are acknowledged by the receiver.  This takes time and that time is not just a question of bandwidth, but it also a question of latency.  If the channel has a 100mS latency, it could take 1/5 second to acknowledge each packet (round trip time).  It might be that the server only permits a certain number of outstanding unacknowledged packets at any given time in case it needs to re-transmit one or some.   If that number happened to be one, you could potentially only get 5 packets per second with that 100mS latency.   At 10 buffered packets it might be 50 packets/sec. 

There is a lot more involved than just channel bandwidth.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

Offline

Board footer

Powered by FluxBB