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
Opened a ticket now too:
Ticket 9699176
BHS6 - Rack: T06G35 - Server ID: 308751
@OVH_Matt
[ YOU HAVE 6193 NEW TICKETS ]
Thats a flood.
Well, hopefully most of you only paid for a month...
BTW As per the Arm servers, its a per thread limit of 50Mbit. If you want to get better speeds, use multiple threads. Use something like Parsync and set it to multiple threads, you can easily hit 500Mbit doing this. I can understand why they are doing this, outbound bandwidth is what is expensive and there is a bunch of servers constantly competing for it. Their solution to keep costs reasonable is to lower costs by placing per thread QoS for outbound. What is more interesting is depending on the destination you will actually see higher bursts, but anything using international bandwidth (read: outside Europe) will see this limitation. I believe earlier in this thread someone said pretty much anything local OVH or that peers directly with OVH are less likely to be limited, while external traffic is, this seems to be my experience as well.
For iperf tests add something like -P <x> (where x is a number greater than 1) to the command to run tests in parallel, if you do this for upload test you will see your overall outbound rate hit a lot more than in a single thread.
I have a ticket open to them to get Kernel sources for the three kernels they use. The kernel on all their Ubuntu/Debian templates lacks tons of kernel features, most notably the ones needed for LUKS encryption. For now, the only really usable template with this in mind is their Openmediavault (32bit) template running an older 4.9.2 kernel which seems to actually have the needed features, but then you got to fight to remove all the Openmediavault settings to have a usable OS. Anyone else already able to get the kernel sources or modules for the other kernel sets? My Ticket is yet unanswered from Friday and I expect won't be answered till sometime later this week.
my 2 cents.
Cheers!
you totally figured it out already...
@TheLinuxBug Didn't know outbound bandwidth was expensive only for TCP traffic... (no such limit when sending UDP packets towards UK and US ASNs...)
Besides the falsely advertised features, these Arm servers are definitely underwhelming, and that's only because of OVH. Stupid boot system, outdated OS images, crippled kernels, no KVM (or overpriced) - looks like they take every possible step t keep them unattractive and needlessly contorted. The sudden price drop is puzzling in this respect.
Honestly, I haven't had it long enough to provide a real observation, but what I can say is if they provided the kernel source so that you could compile your own kernel, even without 'kvm' or console, this is a good deal if you look at it for what it is. Cheap storage. Period.
You can use it for some limited services as well if you like. If you take advantage of things like the crypto engine by recompiling openssl as demonstrated by @rm_ in another thread here on LET, it can allow for pretty efficient transfer rates and enough ram to provide some limited services like NFS, SSHFS, simple web portal, vpn server, etc.
If you are expecting more than that, then you are right, probably not the right fit.
my 2 cents.
Cheers!
Stop being so retarded for fuck's sake, no you can not defend a provider who advertises a server as 250 Mbit unmetered, but then has a hidden hard limit of 5 Mbit. Shove your fucking "2 cents" up your ass and just stop posting ffs.
Luckily, it's all not this bad, and things are looking to be a simple misconfiguration somewhere, something they might be looking to fix, rather than a malicious false advertising and whatnot.
Using iperf with -P 6 I can push 100MB/sec to one of my servers in Netherlands
http://prntscr.com/jvrek3
http://prntscr.com/jvre7p
http://prntscr.com/jvrdkz
I haven't tested to US servers yet, but again, it looks like if you use multi-threading you can get substantially more than you paid for, possibly.
Thanks for your usual positive and uplifting reply.
Cheers!
These Arm-A9 are pretty decent. I can get 20'000 HTTP requests per second served across networks, before maxing 190% cpu (2 cores).
Pretty sure the machine can do even more. Right now I'm trying to lower the software interrupts (Net_rx hogging 30% cpu) so that I can increase the req/s.
how about telling something that wasn't written pages ago...
HE IS A GOD, KNEE BEFORE HIM, INFIDEL!
Check with
ethtool -k eth0 | grep -v fixedwhat it has from the hardware offloads on the NIC that's off but can be changed.Nope, inbound is fine. Outbound is capped no matter if you draw from actual disk IO or /dev/zero
Answer from my ticket. hope they fix it fast.
I interpret that answer as "not my fault, wontfix, deal with it".
They won't fix it.
So, if they dont fix it... could we report it to ARM? How?
Well, move your data elsewhere and don't renew it. I don't buy the explanation for the upstream-only abnormally though.
These ARM issues reminds me of the online.net bios fiasco resulting of abyssal HDD speeds with no fix available.
-edit- nevermind saw that they replied to someone else with the same thing
They just replied to my ticket and they said:
I take that as they're not going to do anything about it.
So they just deployed all these ARM servers without actually testing them?
Location BHS storage 2TB, i got 470mbps to iperf.he.net
The fuck? So the ARM network driver decides, that is not OVH network, throttle it?
Biggest bullshit I ever heard.
@OVH_Matt care to elaborate?
@others Feel free to join the conversation or retweet - https://mobile.twitter.com/K4Y5/status/1008159669850968064
I got the canned response, too. So, they're suggestion is to tell their paying customers that it is on them to contact the hardware vendor regarding this issue? Why should this fall on customers to do? I am assuming that this affects all the ARM servers so, there is no way they can meet the promised bandwidth of 250Mbps.
I'll just let this one expire but, this is a pretty crappy thing to do to your customers.
This issue feels a lot like my old kimsufi issue: https://www.lowendtalk.com/discussion/116410/kimsufi-fr-crappy-network#p1 which was eventually (2 months) resolved by the staff. Ticket #5836123691 on the kimsufi sub-brand if you need a reference for it.