A lot of SYS ARM storage are randomly becoming available

Jona4s

ARM is pretty decent.

$6 SYS for 20'000 req/s across networks, using a compiled language.

On Scaleway, C1 €3 I get ~40k req/s (4 core ARM).

darkimmortal

@TheLinuxBug said:

Actually, you again don't understand what this service was meant for. This was meant as a back-up appliance. If you actually go to archive.org and looked when they first sold these, they were 3x the cost and were basically sold as back-up targets. They were not even meant to really be "servers" to begin with. I think you had the wrong expectations going in.

For this purpose, OVH does provide you with regular operating system and kernel updates. In fact, they released one recently which actually seems to have a usable networking stack since they did some sysctl changes. Even before they 'fixed' the kernel, they supplied this. If you ask me, I think they may have even purposely left the network driver crippled on upload to 50Mbit to help them save money on the products bandwidth. I of course don't think they will ever come forward and admit this. They have said, however, that they are making close to nothing on it now and have discontinued their plans for adding to the platform. I would assume this is because they are losing their ass now since the kernel was patched by us and they are being used as seedboxes by half the users, which was never the intent to begin with. They only released their own 'fixed' kernel because it was pretty much already done by us and they didn't want customers to have to use a third party kernel.

Since your argument is that it needs 'official and regular patches', it is getting this and it is officially being done by OVH, the owner and maintainer of the platform.

A dedicated server is a server, plain and simple. A 'backup appliance' would imply dumb rented storage (FTP, rsync, borg, etc), which is not what this is. Your argument seems to be that because these machine are 'only' used for storage and seedboxes that they are somehow exempt from needing proper security practices?

OVH throwing together a kernel update now and again is not comparable to being able to run upstream kernels and having support from distro maintainers.

@TheLinuxBug said:

ARM is in mainline and slowly getting bigger, the problem is, we have a bunch of people who like to complain instead of pitch in and help make things better and point the finger when things don't work exactly the same as x86. This isn't productive and is exactly the reason progression is so slow. It isn't helped by those who are lazy and want it all done for them out of the box, either.

Agreed, but that isn't me

TheLinuxBug

darkimmortal said: support from distro maintainers.

You missed the part where I said that the repos that are used, are those owned by Debian and Ubuntu, I assume? The packages for ARM are still maintained by the respective distributions. So you are still getting package updates and upgrades as far as I can tell. Especially on the Debian 8/9 templates. As the Ubuntu template seems to be an LTS it may only be receiving LTS package updates there, so less often.

The only packages which are responsible to be maintained by OVH is the kernel and uboot packages, really. With the uboot they are using being specialized it probably doesn't get regular updates, but they do seem to be doing regular kernel releases, at least regular enough to not be back in the stone ages. Then again, if you want something closer to mainline, then keep an eye on the kernels we (#SYSarm) have been releasing as we keep trying to patch newer kernels, as possible, and release them.

Cheers!

sgheghele

Would you go for this one or a cloud solution for non-frequently accessed backups?

Xei

@TheLinuxBug said:

I had no issues with other OVH services/platform when I was having issues with the ARM server. And that has since resolved, whatever it was it was definitely on the ARM end. I don't do anything resource intensive.

@sgheghele said:
Would you go for this one or a cloud solution for non-frequently accessed backups?

If you can afford it, I think it's always nice to have storage boxes, but ultimately I would back everything up to the cloud or another server. Otherwise you have a single point of failure, in this case with dated hardware.

Xei

So my ARM box under no load still loses SSH connectivity [even when basically idle]. All my other OVH stuff works w/o issue. Anyone else have connectivity issues? It probably could be due to bad hardware if it's not something related to the network. In any case it doesn't matter too much since I only picked it up for a month to see test it out. Someone else can deal with it/figure it out.

sgheghele

So I got a 4TB one with Debian Stretch kernel (4.5.2-armada375) (I used the "use distribution kernel option" or whatever it is called).

iperf3 -c ping-ams1.online.net -p 5209 
Connecting to host ping-ams1.online.net, port 5209
 - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  2.17 GBytes  1.86 Gbits/sec    3             sender
[  4]   0.00-10.00  sec  2.17 GBytes  1.86 Gbits/sec                  receiver

iperf Done.

curl -s wget.racing/nench.sh | bash;
-------------------------------------------------
 nench.sh v2019.03.01 -- https://git.io/nench.sh
 benchmark timestamp:    2019-03-30 11:17:51 UTC
-------------------------------------------------

Processor:    ARMv7 Processor rev 1 (v7l)
CPU cores:    2
Frequency:    MHz
RAM:          2.0G
Swap:         510M
Kernel:       Linux 4.5.2-armada375 armv7l

Disks:
mtdblock0      1M  SSD
mtdblock1     64K  SSD
sda    3.7T  HDD

CPU: SHA256-hashing 500 MB
    17.524 seconds
CPU: bzip2-compressing 500 MB
    51.367 seconds
CPU: AES-encrypting 500 MB
    27.145 seconds

ioping: seek rate
    bash: line 220: ./ioping.static: cannot execute binary file: Exec format error
ioping: sequential read speed
    bash: line 222: ./ioping.static: cannot execute binary file: Exec format error

dd: sequential write speed
1st run:    144.96 MiB/s
2nd run:    169.75 MiB/s
3rd run:    164.99 MiB/s
average:    159.90 MiB/s

IPv4 speedtests
your IPv4:    .xxxx

Cachefly CDN:         92.08 MiB/s
Leaseweb (NL):        19.58 MiB/s
Softlayer DAL (US):   12.26 MiB/s
Online.net (FR):      52.35 MiB/s
OVH BHS (CA):         9.02 MiB/s

I guess that I do not need to do anything special with the custom kernel?

Edit: re-added accidentally deleted iperf

Shot2

The "throttling" occurs when uploading, not downloading Should be fine.

If you installed the Debian Stretch template, ensure it has the file /etc/apt/sources.list.d/ovh.list, then simply update your packages to get a "better" (latest and greatest) kernel.

sgheghele

@Shot2 said:
The "throttling" occurs when uploading, not downloading Should be fine.

If you installed the Debian Stretch template, ensure it has the file /etc/apt/sources.list.d/ovh.list, then simply update your packages to get a "better" (latest and greatest) kernel.

Ah sorry, when editing my post I overwrote my iperf test. It makes 1.8gbit/s to ping.online.net. Re-added.

Thanks for the other tip!