New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I think that iperf -c you ran downloads data from the remote host (online.net). To make this crystal clear, imagine a diagram showing your OVH box and the Online server, with an arrow pointing from Online to OVH showing which way the data is flowing.
We know that download (moving data from an external server to the OVH ARM server) works fine. Your benchmark tells us nothing we don't already know. The problem people are seeing is with upload. That means the arrow points in the opposite direction: from OVH to Online. The data moves outward from OVH, not inwards to OVH.
I feel dumb spelling this out in so much detail but enough people have repeated the same useless benchmark that I have to wonder if there is a reading comprehension problem in this place.
no, you might want to read the manual to iperf ;-) default measurement is client -> server while you can reverse that with the -R flag or check both directions with -r ...
also please check the first few pages, the upload behaviour also was checked using wget and ssh and so on.
I think it's a kernel that OVH compiled and delivers with their templates - regardless if you check the 'distro kernel' or not. that simply is because the kernels are named differently in the official repos and there is no such armada kernel there.
most likely they hardcoded some QoS or connection limitation stuff inside it there has to be something which is able to differentiate between dc-internal and external connections... or at least it is marking packets to have the switch be able to filter/limit whatever.
I just finished reinstalling the official debian 9 template on the box and then did that:
(note that this will ask you to abort because it's the running kernel, but that's what we really wanna do, so you need to choose 'no' from the dialog to not abort)
continue:
done.
I did look at the manual and it only described the connection type, not the data transfer direction. If you're sure that the benchmark measured an upload, then that's great, thanks. It should be possible to confirm this with ifstat output.
For me, all my soyoustart servers have the upload problem. ARM, or essential servers, they all have 5Mbps limit per connection.
Tested today:
From SOYOUSTART essential server Canadá - E3-1225- 32gb ram-2x2TB HDD:
From oneprovider France - cheap ATOM C2350 4GB ram 1TB HDD:
Oneprovider near my ISP download limit in a single connection.
Gonna try this now, just waiting on the reinstall to finish.
no worries I am certain ;-) ;-)
just for balls I created a 1G dummy file (urandom) put in on nginx and issued a wget to it from a hetzner server:
what else could I say... I am resting my case and keeping that box, seems very fast now from the looks of it ^^
PS: thanks to anyone who kept pushing and helped narrow down the probable root cause of that stupid limit. honestly would not have thought of that being something they compile into the kernel and keep push that on the box despite one choose to not want it...
Here are the steps I took to resolve:
apt-get install iperfiperf -c iperf.online.net[ 3] 0.0-10.0 sec 382 MBytes 319 Mbits/secThank you everyone and in particular @Falzo and @S3phy for the helpful posts.
Prior to doing this, had the cap as everyone else. Tested the above steps with the Ubuntu 16 template and although I did not try it with Debian 8, I would assume it would work the same.
Thanks, this is great to know-- install OS from the distro instead of the local OVH version. I've had several OVH servers over the years and always used the OVH installation and seemingly been fine, but I haven't used these ARM servers before. Now I'm thinking of ditching my KS-2E in favor of one of the ARM boxes.
So, the speed problem can be resolved by using the official kernel, but how about IPv6?
How are you getting it to use the new kernel? I removed all armada and install regular kernel but it still keeps booting with Linux sysarm 4.5.2-armada375 #1 SMP Tue Oct 25 11:52:56 CEST 2016 armv7l GNU/Linux
-edit- well regardless of what it says it's booting with...just tested speed and IT WORKS! Going to test files served by Nginx now!! Thank you so much @Falzo
root@sysarmsrver:~# iperf -c iperf.online.net
Client connecting to iperf.online.net, TCP port 5001
TCP window size: 43.8 KByte (default)
[ 3] local 54.39.62.160 port 37136 connected with 62.210.18.40 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 378 MBytes 316 Mbits/sec
Just to be sure, did you update GRUB ?
There's no grub packages installed with the Debian 9 template from SYS...was going to install them but didn't want to fuck things up and have to reinstall.
It works though!! Just tested downloading a 200MB file from my SYS ARM to my Ramnode VPS and I was hitting 20MB/sec!
as far as I can see, they removed every single mentioning from the offer pages. so don't bet on that ...
yeah saw that too, obviously it's pulling that string from /proc/sys/kernel/osrelease which did not change during that procedure. I can't tell yet how to change that, maybe have to take a closer look from rescue as that's also hindering further fiddeling with kernel modules. (it should use the manually installed kernel though)
there is no grub ;-)
Oh... you are right... even with the distrib kernel! Strange.
Thanks so much @Falzo and everyone else!
their storage servers allows ssh access and installment of lets encrypt?
What's funny is I'm hitting 50MB/sec on the upload speed and it's supposed to be limited to 250Mbits lol
Yeah, I was hitting 140MB/s to my DO Droplet in NY-3, much much more than the speed advertised. But I guess we shouldn't brag too much about it or take this for granted... :P
would there be any point @falzo to send that to the support and insist it gets passed to the net team in the rare chance it well does?
https://www.soyoustart.com/fr/offres/1801armada01.xml
"/64"
I don't think so.
obviously they compiled that connection limit stuff as some kind of traffic shaping or whatever into the kernel on purpose. so they will already know about and that's also why they can't easily do anything about it. they'd need to change their templates or installation process. it also seems weird that some people even don't get the distro kernel if they choose so...
afaik that .xml isn't directly linked on their normal offer pages, is it?
Just saw this
In French they says that each server has a network connection up to 2.5Gbps o_o
The page in English doesn't have that sentence.
Interesting!
The NIC is 2.5Gbit, but the guarantee is just 250Mbit which you can exceed often.
Nice, replacing armada with 4.9.0-6-arrmp works wonders:
No grub, and
uname -rstill says4.5.2-armada375for some reason.Now I buy their explanation.
But wasn't their explanation "Hey customer, take it up with ARM," not "Oh yeah, hey, we implemented a custom kernel into our templates (even if you tick 'Use distribution kernel') that cripples the upload speed of the NIC."
I guess they wanted us to investigate with ARM, how their custom kernel tramples all over the NIC driver??
Can we do something similar on Ubuntu, to fix the upload speeds?
I installed Debian 9 but when I try to apt install linux-image-4.9.0-5-armmp linux-headers-4.9.0-5-armmp, I get:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-4.9.0-5-armmp
E: Couldn't find any package by glob 'linux-image-4.9.0-5-armmp'
E: Couldn't find any package by regex 'linux-image-4.9.0-5-armmp'
E: Unable to locate package linux-headers-4.9.0-5-armmp
E: Couldn't find any package by glob 'linux-headers-4.9.0-5-armmp'
E: Couldn't find any package by regex 'linux-headers-4.9.0-5-armmp'
What am I doing wrong ?
Thanks !
Try apt install linux-image-4.9.0-6-armmp linux-headers-4.9.0-6-armmp
apt search linux-image
To answer my own question:
Did "apt-cache search linux-headers" to notice I had version 4.9.0-6