OVH/Kimsufi horrible upload speed | What should I do?

Sanjue007

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?

nullroute

cry?

bikegremlin

Improvise, adapt, overcome!

https://www.rfc-editor.org/rfc/rfc2549.html

ralf

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:

Clouvider       | London, UK (10G)          | 96.8 Mbits/sec  | 703 Mbits/sec
Online.net      | Paris, FR (10G)           | 96.8 Mbits/sec  | 704 Mbits/sec

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

Sanjue007

@ralf said:
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:

Clouvider       | London, UK (10G)          | 96.8 Mbits/sec  | 703 Mbits/sec
Online.net      | Paris, FR (10G)           | 96.8 Mbits/sec  | 704 Mbits/sec

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/sec

localhost

You may want to setup bbr and check

deank

In case crying hasn't worked out, you can try suing.

Nekki

Cancel the server and get something that isn’t a piece of shit.

teamacc

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.

Janevski

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

burble

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.

DanSummer

@teamacc said:
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.

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.

dfroe

@burble said:
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.

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.

Sanjue007

Got an answer from CS end

Hello,

We do apologize for the delay, we were informed by our specialists after further investigations that the performance is correct regarding to the bandwidth of the server. The results of the iperf3 are accurate regarding to the intervals set which was for every 2.00 seconds.

They have verified the configurations on their end and there is no QoS applied on the switch and the interface is indeed set to the configuration advertised for a max of 100Mbs. Please note our Kimsufi servers bandwidth are not guaranteed, throughput may fluctuate.

Should you have any further questions or concerns, please do not hesitate to contact us. We thank you for your understanding.