You are not logged in.
- Topics: Active | Unanswered
#1 2020-04-19 06:20:04
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Only fast, speedtest-cli, pacman and curl get good speeds
Hi everyone.
I have a "Positivo 2 em 1 Q432A" pc, motherboard CHT12CP, quad core, 4 GB of RAM, running a pretty stripped down and minimalistic instance of Arch on a USB 3.0 pendrive, all programs updated to its latest versions, and I'm connected to the net through a TP-Link TP-UE300 USB-to-Ethernet Gigabit adapter, with 300 Mbps download and 150 Mbps upload as my nominal speeds, using Mitrastar GPT-2741GNAC-N2 as my "fiber modem".
My issue is that while I ALWAYS get 295+ Mbps download on the fast cli program and 300+ Mbps dl and 150+ ul on speedtest-cli, I only get "compatible" download speeds of 35-36+ MB/sec (i.e. 280-288+ Mbps) on pacman or curl - and that is on a specific server, though lately it seems that, after the first times I download a file from them, when I try it again, it'll be full speed for some 10-20 secs, then go down fast to 2 or 3 MB/sec then climb back up to 9 or 10 MB/sec and stay there for the rest of the download. That could be some sort of server protection that I've unwittingly triggered, since I've had to download the largest single file on Arch's repositories (cuda) a huge number of times to test this with pacman, curl, wget, Firefox, Chromium, etc. Is that even possible?
Anyway, I can't get these speeds on any other sites (e.g. downloading Ubuntu's, Arch's or Debian's isos) or programs. Every time I try, one of these will happen:
1. The download speed will climb fast, then "hit a ceiling" that could be anywhere between 24-36 MB/sec, and then immediately fall even faster to 2 or 3 MB/sec, climb back to anything between 6 to 12 MB/sec and stay there for the rest of the transference;
2. Like the previous one, but when it "hits the ceiling", it starts to "stutter" or get "mini-freeze-ups" for a few secs (inside the program only, all numbers freeze for a few secs, but the mouse, keyboard, etc. are not affected) and then fall; in these cases, the final speeds will be slower, betweem 3 to 5 MB/secs;
3. The speeds will stay between 9-12 MB/sec all the way through;
It might be worth mentioning that every first time I download something with Firefox, everything (this time including mouse, keyboard, etc.) is frozen for some 40 secs then continues as if nothing happened - and it's clear from the download progress that the pc was getting the file while everything was frozen at the measured speed. After that I can get the same file or any other and there'll be no "freezings" whatsoever. Also, depending on the speedtest or download I'm doing on Firefox, I hear some "clicks", but it seems to be only on FF.
Finally, there's rtorrent's case: on a popular download, the speeds will climb REALLY fast, until it's measuring 24-27 MB/sec, but from the changing numbers on downloaded file size, it's actually about 32-40 MB/sec, but the "speedometer" hasn't caught up with it yet. Then, everything inside the program will start to freeze for a few secs a number of times, and the speeds will fall below 5 MB/sec, afterwards climbing back up to anything between 9 and 12 MB/sec, but never go beyond this. If it somehow crosses that threshold again, the "fast fall" will happen again and the "ceiling" speeds will be even lower. Also, it'll get extremely slow to respond to commands after that.
The best metaphor I can get for the really fast speed fall is this: imagine the download speeds are a tennis ball; you take it and throw it up with all your strength, then it hits the ceiling (and it may or may not be stuck there for a few secs). Now it somehow comes back down not only with all the strength you threw it up, but with the added force of gravity - that's how fast and how much the speed will fall.
Using TP-UE300 on USB 3.0 or 2.0 doesn't make any difference, nor does the value of net.ipv4.tcp_ecn. Also, on Windows 10, MS Edge tends to get better dl speeds than Firefox, and the Speedtest app also always gets 300+ Mbps dl and 150+ Mbps ul.
Does anyone have a clue what's happening here? Could it be that my pc can't handle these dl speeds? But if that was the case, shouldn't the fast program and speedtest-cli have issues getting those speeds? And why does pacman and curl get max speeds from a specific server but no other program can?
Here's lshw and, if there's anything I should post, please just tell me:
[x@archlinux ~]$ sudo lshw
[sudo] senha para root:
archlinux
description: Notebook
product: CHT12CP (3601127)
vendor: Positivo Tecnologia SA
version: Tablet
serial: 4A675V90H
width: 4294967295 bits
capabilities: smbios-3.1 dmi-3.1 smp vsyscall32
configuration: boot=normal chassis=notebook family=CHT12CP sku=3601127 uuid=0C021ECE-9052-0244-8EEA-9A5C1ECE9052
*-core
description: Motherboard
product: CHT12CP
vendor: Positivo Tecnologia SA
physical id: 0
version: 11130211
serial: 4A675V90H
slot: family
*-firmware
description: BIOS
vendor: Positivo Tecnologia SA
physical id: 0
version: V00.06.X
date: 09/21/2017
size: 64KiB
capacity: 3008KiB
capabilities: pci upgrade shadowing cdboot bootselect edd int9keyboard int14serial int17printer int10video acpi usb zipboot biosbootspecification netboot uefi
*-cpu
description: CPU
product: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
serial: To Be Filled By O.E.M.
slot: CHV
size: 941MHz
capacity: 1920MHz
width: 64 bits
clock: 83MHz
capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear cpufreq
configuration: cores=4 enabledcores=4 threads=4
*-cache:0
description: L1 cache
physical id: 6
slot: L1 Cache
size: 32KiB
capacity: 32KiB
capabilities: synchronous internal write-back instruction
configuration: level=1
*-cache:1
description: L2 cache
physical id: 7
slot: L2 Cache
size: 1MiB
capacity: 1MiB
capabilities: synchronous internal write-back unified
configuration: level=2
*-cache
description: L1 cache
physical id: 5
slot: L1 Cache
size: 24KiB
capacity: 24KiB
capabilities: synchronous internal write-back data
configuration: level=1
*-memory
description: System Memory
physical id: 17
slot: System board or motherboard
size: 4GiB
*-bank
description: DIMM DDR3 Synchronous 1066 MHz (0,9 ns)
vendor: 0000
physical id: 0
serial: 00000000
slot: ChannelA-DIMM0
size: 4GiB
width: 16 bits
clock: 1066MHz (0.9ns)
*-pci
description: Host bridge
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register
vendor: Intel Corporation
physical id: 100
bus info: pci@0000:00:00.0
version: 36
width: 32 bits
clock: 33MHz
configuration: driver=iosf_mbi_pci
resources: irq:0
*-display
description: VGA compatible controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 36
width: 64 bits
clock: 33MHz
capabilities: pm msi vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
resources: irq:117 memory:90000000-90ffffff memory:80000000-8fffffff ioport:1000(size=64) memory:c0000-dffff
*-multimedia
description: Multimedia controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit
vendor: Intel Corporation
physical id: 3
bus info: pci@0000:00:03.0
version: 36
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list
configuration: driver=intel_atomisp2_pm latency=0
resources: irq:255 memory:91000000-913fffff
*-generic:0
description: Signal processing controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller
vendor: Intel Corporation
physical id: b
bus info: pci@0000:00:0b.0
version: 36
width: 64 bits
clock: 33MHz
capabilities: msi pm bus_master cap_list
configuration: driver=proc_thermal latency=0
resources: irq:167 memory:91818000-91818fff
*-usb
description: USB controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller
vendor: Intel Corporation
physical id: 14
bus info: pci@0000:00:14.0
version: 36
width: 64 bits
clock: 33MHz
capabilities: pm msi xhci bus_master cap_list
configuration: driver=xhci_hcd latency=0
resources: irq:119 memory:91800000-9180ffff
*-usbhost:0
product: xHCI Host Controller
vendor: Linux 5.6.4-arch1-1 xhci-hcd
physical id: 0
bus info: usb@1
logical name: usb1
version: 5.06
capabilities: usb-2.00
configuration: driver=hub slots=7 speed=480Mbit/s
*-usb:0
description: Generic USB device
product: USB 10/100/1000 LAN
vendor: TP-LINK
physical id: 2
bus info: usb@1:2
version: 30.00
serial: 000001000000
capabilities: usb-2.10
configuration: driver=r8152 maxpower=180mA speed=480Mbit/s
*-usb:1
description: Video
product: USB 2.0 Web Camera
vendor: Alcor Micro, Corp.
physical id: 3
bus info: usb@1:3
version: 0.08
capabilities: usb-2.00
configuration: driver=uvcvideo maxpower=200mA speed=480Mbit/s
*-usb:2
description: Keyboard
product: USB KEYBOARD
vendor: HAILUCK CO.,LTD
physical id: 4
bus info: usb@1:4
version: 1.00
capabilities: usb-1.10
configuration: driver=usbhid maxpower=100mA speed=1Mbit/s
*-usbhost:1
product: xHCI Host Controller
vendor: Linux 5.6.4-arch1-1 xhci-hcd
physical id: 1
bus info: usb@2
logical name: usb2
version: 5.06
capabilities: usb-3.00
configuration: driver=hub slots=6 speed=5000Mbit/s
*-usb
description: Mass storage device
product: Ultra Fit
vendor: SanDisk
physical id: 1
bus info: usb@2:1
version: 1.00
serial: 4C530001190318108265
capabilities: usb-3.00 scsi
configuration: driver=usb-storage maxpower=896mA speed=5000Mbit/s
*-generic:1
description: Encryption controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine
vendor: Intel Corporation
physical id: 1a
bus info: pci@0000:00:1a.0
version: 36
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list
configuration: driver=mei_txe latency=0
resources: irq:166 memory:91700000-917fffff memory:91600000-916fffff
*-isa
description: ISA bridge
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU
vendor: Intel Corporation
physical id: 1f
bus info: pci@0000:00:1f.0
version: 36
width: 32 bits
clock: 33MHz
capabilities: isa bus_master cap_list
configuration: driver=lpc_ich latency=0
resources: irq:0
*-battery
description: Lithium Ion Battery
product: SR Real Battery
vendor: Intel SR 1
physical id: 1
version: Date
serial: 123456789
slot: I2C2
configuration: voltage=3,8V
*-power UNCLAIMED
description: OEM Define 1
product: OEM Define 5
vendor: OEM Define 2
physical id: 2
version: OEM Define 6
serial: OEM Define 3
capacity: 42mWh
*-scsi
physical id: 3
bus info: scsi@0
logical name: scsi0
capabilities: scsi-host
configuration: driver=usb-storage
*-network:0
description: Ethernet interface
physical id: 4
logical name: enp0s20u2
serial: d0:37:45:6d:9a:b0
size: 1Gbit/s
capacity: 1Gbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v1.11.11 duplex=full firmware=rtl8153a-3 v2 02/07/20 ip=192.168.0.86 link=yes multicast=yes port=MII speed=1Gbit/s
*-network:1 DISABLED
description: Wireless interface
physical id: 5
logical name: wlan0
serial: 58:b3:fc:cb:1e:12
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rtl8723bs driverversion=5.6.4-arch1-1 multicast=yes wireless=unassociatedThank you very much in advance,
xenobro.
Offline
#2 2020-04-19 06:55:28
- seth
- Member
- Registered: 2012-09-03
- Posts: 60,972
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Disk I/O?
Did you try comparing the wget/curl download of a largefile to /dev/null and ~/test.img?
Offline
#3 2020-04-20 08:13:52
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Hi, seth, thank you for your reply. I tried what you suggested and here are the results:
curl -o /dev/null http://archlinux.c3sl.ufpr.br/community/os/x86_64/cuda-10.2.89-5-x86_64.pkg.tar.zstDoing this 10 times in a row and at other moments, the lowest speed was 33.3 MB/sec, but mostly between 35.5 and 36.3 MB/sec, so that recent issue of the speed dropping some 10 or 20 seconds in after the first download seems to be related. So I checked the disk i/o with the command below:
iozone -I -s2g -r1024k -i0 -i1Write/rewrite speeds can go from 9 to 61 MB/sec, but usually between 10 to 20 MB/sec, so this could be the bottleneck of this specific issue. Any idea why could there be so much variation here? Read/reread speeds are always 115-123 MB/sec. Also, changing 2GB to 1GB makes no difference.
Anyway, the main issue remains - downloading to /dev/null or RAM seemed to have no effect on the other cases:
wget http://archlinux.c3sl.ufpr.br/community/os/x86_64/cuda-10.2.89-5-x86_64.pkg.tar.zst -O /dev/nullHere, as usual, the speeds were all over the place: from 0 to 32.8 MB/sec, down to 5, back up to 11, climbing up to 15, coming down to 8 and so on, but mostly 10-11 MB/sec with some random climbings to 15 followed by drops to 6 or 7, before coming back up to 10 or 11. One thing I noticed is that the "higher" the max (i.e. 27-32 MB/sec), the lower the min (i.e. 0-2 MB/sec), before stabilizing at ~11 MB/sec. For instance, if it only went up to 15 MB/sec, the drop would be to 7 or 8 MB/sec before coming back to 11 MB/sec.
And Firefox saving to my home folder (on RAM) gets exactly the same results as wget saving to /dev/null.
So, what could be causing these variations and low speeds?
As an aside, I also decided to test other servers from my mirrorlist and confirmed that I can only get 35+ MB/sec speeds from this one specific server. Does anyone get these speeds from any other server that they could suggest to me? If it was from South America, all the better, but from anywhere would be nice.
Thank you very much again,
xenobro.
Last edited by xenobro (2020-04-20 08:27:14)
Offline
#4 2020-04-20 13:33:06
- seth
- Member
- Registered: 2012-09-03
- Posts: 60,972
Re: Only fast, speedtest-cli, pacman and curl get good speeds
https://gist.github.com/raulmoyareyes/3 … c93be64746
The 100MB linode files should have "1GB" variants
Random arch mirrors are generally not very good test servers because you don't know what you get and the server performance could be impacted by the current overall load.
However the difference seems to be between wget and curl?
(You suggest to have downloaded the same file from the same server into /dev/null but curl outperforming wget 3:1, correct?)
Offline
#5 2020-04-21 23:00:07
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Hi, seth, and thank you once again for your help.
As you mentioned, the main problem here is curl/pacman outperforming wget/firefox 3:1 (and sometimes even 6:1), but also the fact that I can only get these speeds from one specific server on the entire Internet - trying to get ubuntu, debian or even arch isos, for instance, or even Win10 from the official MS site never gets these dl speeds, and I'm pretty sure that, in these cases, they should. I mean, can you test and see if you get more than 30 MB/sec dl'ing any of those?
As for the Arch servers, I used that one to measure it because it's pretty much the only place where I can get the full dl speed, but I'm also looking for new ones with good bandwidths, since most servers in the brazilian mirrorlist are public universities, and those have been having their funds severely cut by the federal gov't, so they might not even exist as servers for much longer, or will have to cut down expenses to a minimum, which might lead to dl speed decreases to make less machines serve the same amount of people, since they're having to cut down even on the electricity bills.
But anyway, I went to the site you suggested and did every test there was there. As you will see below, strangely only the Cachefly main site got me the full dl speeds, and for a change, that happened on curl, wget and even Firefox.
Most other tests had about the same results with wget and curl, but with lower speeds to both. Also, the variation in many of those was huge: the same test would get 0.3 MB/sec throughout its duration, and then would go on to get 20 MB/sec for the next 3 times, then go back to 0.4 MB/sec.
Some things I noticed on all dl tests except Cachefly: the speed up was generally slow; the first time I did a test was almost always the worst - by a factor of 10x to 100x, like 0.2 MB/sec in the 1st test to 20 MB/sec in the second); wget seemed to fail a lot with ipv6, which would never happen to curl.
Another thing is that my ul speeds seem to be, in general, much, much slower than they should be: speedtest-cli, fast and speedtest on Firefox always get me 150+ Mbps, so I should be getting some 16+ MB/sec, but even on rtorrent I've never gotten more than 2 MB/sec, and from the tests at the end of this post, you can see that, many times it's even lower than that - only the last test gave me a reasonable but still very slow result.
Finally, each of those tests was performed 3-10 times in a row; the first result is the lowest final result speed gotten from all of those, and the second, the highest final result. "Failed" means the site has 404'd unless stated otherwise.
Once again, thank you very much in advance,
xenobro.
BENCHMARKING
Here, results were almost the same for both wget and curl: among the many servers, 4.87-13.01 MB/sec dl, 0.37-7.26 MB/sec ul, only North American ramnode servers and one from vortexservers responded, all others giving me 0 MB/sec dl and ul, CPU reported as 4 x Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, time to generate PI to 5000 decimal places with a single thread ~0m51s and IO test ~611 MB/sec (home folder on RAM).
DOWNLOAD
Cachefly:
wget -O /dev/null http://cachefly.cachefly.net/100mb.test35.3 MB/sec
curl -o /dev/null http://cachefly.cachefly.net/100mb.test34.4 MB/sec
Here, even Firefox got max speeds, since I couldn't even measure it, because the 100 MB dl was was over in less than 1 sec.
wget -O /dev/null http://speedtest.dal01.softlayer.com/downloads/test100.zip
curl -o /dev/null http://speedtest.dal01.softlayer.com/downloads/test100.zipFailed
wget -O /dev/null http://speedtest.sea01.softlayer.com/downloads/test100.zip
curl -o /dev/null http://speedtest.sea01.softlayer.com/downloads/test100.zip13.8-16.0 MB/sec
wget -O /dev/null http://speedtest.ams01.softlayer.com/downloads/test500.zipUp to 13 MB/sec, down to 18 KB/sec, sometimes maxing until the end, sometimes at the minimum all the way through.
curl -o /dev/null http://speedtest.ams01.softlayer.com/downloads/test500.zipSlowly up to 12-13 MB/sec, sometimes dropping to 9.9 MB/sec.
wget -O /dev/null http://50.23.64.58/downloads/test100.zip14.2-16.4 MB/sec
curl -o /dev/null http://50.23.64.58/downloads/test100.zip14.7-16.0 MB/sec
wget -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zipFails on ipv6, 22.8-24.7 MB/sec on ipv4
curl -o /dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip21.1-22.7 MB/sec
wget http://speedtest.wdc01.softlayer.com/downloads/test10.zip > /dev/nullFails on ipv6, 2.73-2.75 MB/sec on ipv4 - seemingly not enough time to reach higher speeds
curl -O http://speedtest.wdc01.softlayer.com/downloads/test10.zip > /dev/null2399-2540 KB/sec on ipv4 - seemingly not enough time to reach higher speeds
wget --output-document=/dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip21.5-24.6 MB/sec
curl --output /dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip21.5-21.9 MB/sec
echo `curl --progress-bar -w "%{speed_download}" http://speedtest.wdc01.softlayer.com/downloads/test10.zip -o test.zip|sed 's/....$//'`/
131072|bc|xargs -I {} echo {} MB/sec14 MB/sec
Linode:
wget -O /dev/null http://speedtest.tokyo.linode.com/100MB-tokyo.bin
curl -o /dev/null http://speedtest.tokyo.linode.com/100MB-tokyo.binFailed
wget -O /dev/null http://speedtest.london.linode.com/100MB-london.bin10.8-11.6 MB/sec
curl -o /dev/null http://speedtest.tokyo.linode.com/100MB-tokyo.bin10.9-11.8 MB/sec
wget -O /dev/null http://speedtest.newark.linode.com/100MB-newark.bin12.2-17.8 MB/sec
curl -o /dev/null http://speedtest.newark.linode.com/100MB-newark.bin17.3-17.6 MB/sec
wget -O /dev/null http://speedtest.atlanta.linode.com/100MB-atlanta.bin11.0-18.8 MB/sec, mostly 18+
curl -o /dev/null http://speedtest.atlanta.linode.com/100MB-atlanta.bin11.6-18.7 MB/sec, mostly 18+
wget -O /dev/null http://speedtest.dallas.linode.com/100MB-dallas.bin2.15-16.9 MB/sec, mostly 16+
curl -o /dev/null http://speedtest.dallas.linode.com/100MB-dallas.bin1.4-16.5 MB/sec
wget -O /dev/null http://speedtest.fremont.linode.com/100MB-fremont.bin5.8-13.0 MB/sec
curl -o /dev/null http://speedtest.fremont.linode.com/100MB-fremont.bin11.3-11.7 MB/sec
wget -O /dev/null http://mirror.nl.leaseweb.net/speedtest/1000mb.bin11.8-12.9 MB/sec
curl -o /dev/null http://mirror.nl.leaseweb.net/speedtest/1000mb.bin12.6-12.8 MB/sec
wget -O /dev/null http://mirror.us.leaseweb.net/speedtest/1000mb.bin12.0-17.7 MB/sec
curl -o /dev/null http://mirror.us.leaseweb.net/speedtest/1000mb.bin11.2-15.0 MB/sec
wget -O /dev/null http://lg.denver.fdcservers.net/100MBtest.zip
curl -o /dev/null http://lg.denver.fdcservers.net/100MBtest.zipFailed
wget -O /dev/null http://proof.ovh.net/files/100Mb.dat3.57-4.90 MB/sec - seemingly not enough time to reach higher speeds
curl -o /dev/null http://proof.ovh.net/files/100Mb.dat2916-4078 KB/sec - seemingly not enough time to reach higher speeds
UPLOAD
iperf3 -c iperf.scottlinux.com -u
iperf3 -c iperf.volia.net -R -P 4Failed
iperf -c iperf.volia.net -r -P 4267 Kbps
iperf -c s-network1.amcs.tld -P 1 -i 5 -p 5999 -f B -t 60 -T 1
iperf -c iperf.acd.net -P 10 -t 240Failed
iperf -c ping.online.net -i 2 -t 20 -rFailed - connection refused
bwctl -T iperf3 -f m -t 10 -i 1 -c ps.ncar.xsede.orgCouldn't find bwctl
iperf -c ping.online.net -i 5 -u -r1.05 Mbps
iperf -c ping-90ms.online.net -i 5 -u -r988 Kbps
iperf -c debit.k-net.fr -i 10 -T 100Failed
iperf -c speedtest.serverius.net67.5 Kbps
iperf -c iperf.he.net57.2 Mbps
Offline
#6 2020-04-22 05:54:46
- seth
- Member
- Registered: 2012-09-03
- Posts: 60,972
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Downloads some live distro (grml, knoppix, …) and test the behavior there. This is probably a routing issue and the results are rather random.
I cannot test their max performance from here, because, for the time being, the fastest (and only) connection I can get is 30MBit/s …
Offline
#7 2020-04-24 07:07:28
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Hi, seth, and thank you once again.
I'll do what you say and dl grml, knoppix, ubuntu (if there's a live mode) and debian (and maybe alpine) to check how wget/firefox fare against curl, but this will take a few days: I'll update as I go. What tests should I run though? The same from the page you posted, trying to dl random things or isos with wget/firefox and curl or both?
Also, while the results from the latest tests were pratically the same with wget and curl, if it was a routing issue, why should there be such a big difference when dl'ing anything from the high speed arch server? And also, the problem only seems visible when curl's getting higher speeds, like 30+ MB/sec, while on lower speeds they seem to get about the same...
Finally, what routing issues could be happening? If that's the case, is there anything I can do to correct this?
Anyway, just out of curiosity, how much MB/sec dl are you getting on your 30 Mbps, just so I know how much I should expect?
Thank you once again and I'll update as I run the tests,
xenobro.
Last edited by xenobro (2020-04-24 07:12:31)
Offline
#8 2020-07-17 20:52:52
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Hi, seth and everyone.
Sorry for taking so long to reply: there's been a lot going on here with the pandemic, so I couldn't really take time to do the necessary tests until recently.
Anyway, I reran all the tests 3-5 times each, with both wget and curl, on grml and Alpine (Knoppix didn't boot for some reason), and actually got almost exactly the same results, even though it's been 3 months since the original tests. The few ones that came different, when I ran them again in Arch, got the same results as on the 2 others now.
So while these may seem random when comparing speeds gotten between sites, they're actually extremely consistent when you compare the many results you get from each site even throughout 3 months.
Also, as I predicted, one of the few sites where I got 35+ MB/sec speeds, archlinux.c3sl.ufpr.br, now can't go over 12-15 MB/sec. In its place however, br.mirror.archlinux-br.org now gets 35+ most of the time. Cachefly and a few others throughout the net still get it constantly without any problems, while most sites don't.
Any ideas on what should or could I do?
Thank you very much, xenobro.
Last edited by xenobro (2020-07-17 20:54:13)
Offline
#9 2020-07-21 03:57:16
- xenobro
- Member
- Registered: 2019-05-25
- Posts: 102
Re: Only fast, speedtest-cli, pacman and curl get good speeds
Oh, also some random file download sites throughout the net can give me those speeds more often than "normal" sites, if that makes any sense.
Any ideas? Can somebody help me figure out why the slow speeds on many others that should be getting way better performance?
Thank you very much, xenobro.
Offline