OVH/Kimsufi horrible upload speed | What should I do?
Hi
I owned a KS-LE server from their last BF offer. When I purchased it was 1Gbps full duplex but unfortunately it didn't last longer. It lasts only for few weeks. Nevermind i was happy only the upload got affected. But since few days upload speed is not more than 35Mbps. Opened a ticket and they said we can't guaranteed the bandwidth in Kimsufi. Only motherboard got replaced. Nothing happened.
root@rescue:~# iperf3 -c bhs.proof.ovh.ca -4
Connecting to host bhs.proof.ovh.ca, port 5201
[ 4] local 158.xx.xx.xx port 58092 connected to 51.222.154.207 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 5.14 MBytes 43.1 Mbits/sec 796 2.83 KBytes
[ 4] 1.00-2.00 sec 2.98 MBytes 25.0 Mbits/sec 449 1.41 KBytes
[ 4] 2.00-3.00 sec 3.85 MBytes 32.3 Mbits/sec 517 1.41 KBytes
[ 4] 3.00-4.00 sec 4.23 MBytes 35.4 Mbits/sec 722 1.41 KBytes
[ 4] 4.00-5.00 sec 3.48 MBytes 29.2 Mbits/sec 517 1.41 KBytes
[ 4] 5.00-6.00 sec 4.47 MBytes 37.5 Mbits/sec 624 1.41 KBytes
[ 4] 6.00-7.00 sec 3.73 MBytes 31.3 Mbits/sec 576 2.83 KBytes
[ 4] 7.00-8.00 sec 4.47 MBytes 37.5 Mbits/sec 712 4.24 KBytes
[ 4] 8.00-9.00 sec 4.23 MBytes 35.4 Mbits/sec 680 4.24 KBytes
[ 4] 9.00-10.00 sec 4.23 MBytes 35.4 Mbits/sec 696 1.41 KBytes[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 40.8 MBytes 34.2 Mbits/sec 6289 sender
[ 4] 0.00-10.00 sec 40.6 MBytes 34.1 Mbits/sec receiver
What can i do other than giving up on this server?
Comments
cry?
https://purplehost.com.br - Reliable, secure and affordable game hosting.
Improvise, adapt, overcome!
https://www.rfc-editor.org/rfc/rfc2549.html
BikeGremlin I/O
Mostly WordPress ™
Maybe you're just unlikely, or maybe this is only in their Canada data centre, or maybe they restricted your bandwidth due to overuse.
My BF KS-LE-1 still gets good iperf results, but it only really gets used for admin tasks like hosting my internal mail, git repos and CI so doesn't have a great deal of external traffic, maybe only 10GB per day. From today:
BTW you left your IP address in your iperf output, might want to get an admin to edit it out for you.
OTOH, I do kind of suspect some random problem somewhere in OVH's network. A couple of months ago, I ordered a second KS-1 and that had great network connectivity but as soon as it passed from OVH France to OVH US the transfer rate dropped off a cliff and ended up similar to yours. It was definitely a routing issue somewhere in the US, but only that subnet was affected and another KS-1 in the same data centre didn't have the same issues. They eventually acknowledged there was a problem and refunded it, but I imagine they never tracked down the problem or they would have just fixed it. Unlikely to be exactly the same issue for you if you're only doing CA to CA. But just in case, my post was here: https://lowendtalk.com/discussion/179761/cannot-get-ovh-to-respond-to-terrible-network-throughput
thanks for pointing that out.
well unfortunately these are my yabs results on the server
iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | | | Clouvider | London, UK (10G) | 36.8 Mbits/sec | 172 Mbits/sec Online.net | Paris, FR (10G) | 34.8 Mbits/sec | busy Hybula | The Netherlands (40G) | 30.2 Mbits/sec | 634 Mbits/sec Uztelecom | Tashkent, UZ (10G) | 18.6 Mbits/sec | 166 Mbits/sec Clouvider | NYC, NY, US (10G) | 92.9 Mbits/sec | 454 Mbits/sec Clouvider | Dallas, TX, US (10G) | 57.6 Mbits/sec | 153 Mbits/sec Clouvider | Los Angeles, CA, US (10G) | 31.1 Mbits/sec | 191 Mbits/secYou may want to setup bbr and check
In case crying hasn't worked out, you can try suing.
♻ Amitz day is October 21.
♻ Join Nigh sect by adopting my avatar. Let us spread the joys of the end.
Cancel the server and get something that isn’t a piece of shit.
https://lowendtalk.com/discussion/116410/kimsufi-fr-crappy-network
I've had similar results in the past. After enough complaining, they put the server on gigabit network just to get rid of my tickets.
Hey teamacc. You're a dick. (c) Jon Biloh, 2020.
Back in the days, when my cable provider promised 8Mbps and delivered, like ~0.5Mbps i used download accelerator - axel, to get something close to line speed.
sudo apt-get update
sudo apt-get install -y axel
cd ~/Downloads
axel -n 45 --user-agent "Mozilla/5.0 (Linux; Android 12; SM-S906N Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/80.0.3987.119 Mobile Safari/537.36" --header "Referer: https://mirror.koddos.net" https://mirror.koddos.net/knoppix/KNOPPIX_V7.0.5CD-2012-12-21-EN.iso
https://linux.die.net/man/1/axel
https://github.com/axel-download-accelerator/axel
Educationally teaches you with knowledge, while you learn and conglomeratively alluminate your academic intellectual profile: https://lowend.wiki
„Homo homini rattus.“
OVH rate limiting decimates outgoing packets.
Specifically, that means if you have a burst of traffic your server can send packets out at the interface rate (1gbps) but OVH will simply throw some away in order to limit the upstream bandwidth. With TCP this usually isn't too much of a problem, TCP will adapt to the packet loss and your data will get there after retries, however it will hurt more as the latency increases. Non-TCP traffic is a disaster though and it can cause chaos if, for example, you are tunnelling traffic over an IPSec or UDP VPN.
There is a simple fix for this and that is simply to implement rate limiting on your server so that traffic queues nicely on your host before getting sent out at the correct rate, avoiding any packet loss. I used Fireqos on linux (which is just a wrapper around tc) and the difference is night and day; not only in getting the most upstream performance, but also maxing out that 1gbit downstream as well.
Lucky you. I've been having the same problem with a SYS server for months! I can't even get support to acknowledge the issue.
In my case, the outgoing speed is exactly as advertised but the incoming (which is usually around 1000 Mbits/sec) is terrible -less than 80 Mbits/sec to most US locations.
This only applies if your actual data traffic within the tunnel is also non-TCP. Which is rather unusual because most applications use TCP.
The outer tunnel should never add an additional TCP encapsulation. This would result in two TCP flows encapsulated in each other with each having its own flow control unaware of the other.
TCP relies on packet drop as feedback to determine an appropriate data rate. Similiar as the OVH server being rate limited at the datacenter boundary, your personal internet link forces your own router to sometimes drop packets from your PC as well. Just because your PC is not aware of the speed of your internet uplink.
Encapsulating TCP in TCP, for example by using a TCP-based VPN, may often significantly decrease performance in terms of throughput and jitter. When data is sent to fast and thus being dropped, the outer TCP algorithm might initiate a packet retransmission before the inner one. As a result the inner TCP flow does not notice any packet loss (just some jitter) and depending on the actual implementation of the congestion control algorithm, the inner TCP flow might not reduce throughput properly or in an unexpected way. Or both TCP flows perform retransmissions at the same time resulting in duplicated packets and thus reduced throughput.
The goal of a VPN encapsulation is to add privacy, not to add an additional layer of flow/congestion control.
it-df.net: IT-Service David Froehlich | Individual network and hosting solutions | AS39083 | RIPE LIR services (IPv4, IPv6, ASN)
Got an answer from CS end