All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Serverum review and benchmark
Serverum, a new provider, offered some "intro" deals in december 2018 -> https://www.lowendtalk.com/discussion/comment/2934625. I offered to make a benchmark and review and the Serverum people were friendly enough to provide a VPS for testing for about a month. I would like to thank them for providing a test VPS.
Front-up: I can't say anything about their support because I simply didn't need it. Everything just worked fine.
Here is the system data:
Machine: amd64, Arch.: x86_64, Model: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
OS, version: Linux 3.10.0, Mem.: 1.814 GB
CPU - Cores: 2, Family/Model/Stepping: 6/62/4
Cache: 32K/32K L1d/L1i, 2M L2, 16M L3
Std. Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 cflsh mmx fxsr sse sse2 ss sse3 pclmulqdq ssse3 cx16 pcid
sse4_1 sse4_2 x2apic popcnt tsc_deadline aes xsave osxsave avx f16c
rdrnd hypervisor
Ext. Flags: fsgsbase tsc_adjust smep erms syscall nx pdpe1gb rdtscp lm lahf_lm
The KVM VPS came with 40 GB disk space and 2 GB memory, about 1.8 GB of which were available after booting. The OS was CentOS 7 it seems.
The following is the result of processing many tests that were run during the test period randomly at different times of day.
Proc/mem single-core avg: 283.8 (min: 276.5, max 285.4)
Proc/mem multi-core avg: 588.4 (min: 565.0, max 611.4)
Disk Test seq. write avg: 1485.0 [MB/s] (min: 1239.0, max 1661.0)
Disk Test rnd. write avg: 1850.0 [MB/s] (min: 1466.0, max 2069.0)
Disk Test seq. read avg: 4282.8 [MB/s] (min: 3337.0, max 4749.0)
Disk Test rnd. read avg: 3822.7 [MB/s] (min: 3222.0, max 4268.0)
Net Test AU, MEL avg: 38.7 [Mb/s] (min: 32.2, max 43.8)
Net Test IN, CHE avg: 31.9 [Mb/s] (min: 0.7, max 61.1)
Net Test UK, LON avg: 81.8 [Mb/s] (min: 58.1, max 89.3)
Net Test DE, FRA avg: 79.1 [Mb/s] (min: 41.1, max 91.5)
Net Test IT, MIL avg: 76.9 [Mb/s] (min: 30.1, max 89.4)
Net Test FR, PAR avg: 80.8 [Mb/s] (min: 45.3, max 89.6)
Net Test RO, BUC avg: 50.6 [Mb/s] (min: 0.0, max 91.1)
Net Test GR, UNK avg: 52.1 [Mb/s] (min: 20.1, max 67.0)
Net Test RU, MOS avg: 12.0 [Mb/s] (min: 10.8, max 13.3)
Net Test US, DAL avg: 44.9 [Mb/s] (min: 4.2, max 66.7)
Net Test US, SJC avg: 43.1 [Mb/s] (min: 2.3, max 61.6)
Net Test US, WDC avg: 44.8 [Mb/s] (min: 2.6, max 70.1)
Net Test BR, SAO avg: 53.2 [Mb/s] (min: 35.0, max 58.7)
Net Test JP, TOK avg: 56.8 [Mb/s] (min: 38.0, max 60.8)
Net Test NO, OSL avg: 75.8 [Mb/s] (min: 46.9, max 89.7)
Discussion, observations, and remarks:
The processor and memory tests, both single and multi core, showed not impressive but nice results. For comparison, the numbers on a 4 core (vbox) VM on a Ryzen 1700 are 348.27 and 638,15.
The disk tests showed a good (but not top) performance for an SSD. There were occasional points of weaker performance but generally the disk performance was within 10% of the disks top performance.
The connectivity tests were somewhat disappointing. Even very "easy" and classical European targets like NL_AMS, DE_FRA, UK_LON stayed below 100 Mb/s. Also the major cross-Atlantic targets like US_WDC showed hardly half of what many other providers achieve on similar VPSs.
Summary
I'm not at all impressed by the VPS - but one should keep in mind that Serverum is a rather fresh player and probably still in the process of optimizing their infrastructure and products.
Considering their prices (incl. LET offer) I'd keep observing Serverums further evolution but would stay away for the moment as there are quite many clearly better and cheaper options available on LET.
Disclaimer: I'm not and have never been a Serverum customer and I did not ask for or receive anything (other than the needed couple of weeks test access) from Serverum and they also did not ask any favours or anything else whatsoever. The provided VPS was used only and exclusively for testing/benchmarking.
Comments
Very nice and straight to the point review! I agree that you would have expected better performance from a new provider but oh well I guess.
Good review regardless, looking forward to more
what kind of benchmark did you use, @jsg?
The one I always use. Vpsbench, which is linked in my signature.
Do you really consider that disk speed as just “ good “?
Yes. I've tested quite some servers at different providers and think that's a fair judgement. In fact, there is an example here at LET, my review of @RootNerds where the disk test results were
And I can trust my test results because the benchmark software has been designed to not be easily fooled, in particular in the random read and write tests. Obviously in the above Rootnerds results the node had plenty cache and probably nvme disks but in the end I only care about what a customer really gets.
Those are pretty large min and max's, with a worse min at one point. Those results will be less consistent than what you reviewed.
Remind me, which real world test load that a customer would actually get?
You didn't really find anything wrong, and you didn't review the panel and reimaging, so it really comes down to competitive pricing.
p.s. regarding the 100Mbps speed expectation across the pond, in before Clouvider says that's not how networks work.
Yes, absolutely - and to be expected on an OVZ VPS.
None - and I'm not too happy about that. But the problem is that a benchmark just can't make reasonable statements about real world customer loads; there are way too many and too different ones.
So I decided to take another route and to go for "honest real" results - which almost none of the commonly used benchmarks give. Example with testing disks: unlike dd (which is quite primitive for a load test) based batch scripts vpsbench does truly random disk reading and writing. Random as in "the load itself (the data) is random and the pattern (where to read/write) is random too" which makes "optimizing" for test (some call it cheating) quite hard but which also shows large discrepancies like those at the Rootnerds VPS - because they are there, they are typical for OVZ.
And I didn't say so. I didn't say "something is wrong". I simply reported results of a multi-week test series and I expressly stated that I can't judge their support because I didn't have to use it; and I mentioned the reason: everything worked fine.
Meanwhile I have done quite some tests at different providers and different hypervisors and fact is that I've seen way better than 100 Mb/s cross atlantic more that rarely.
No, it was KVM:
Oops, you are right, I made an error, sorry. Also apologies to @Serverum.
@doghouch or @PieNotEvenEaten
Unfortunately I can't edit my OP anymore. Could one of you moderators please kindly correct my mistake by deleting "(the offer here at LET was an OVZ)"? It's in the first sentence right after the first yellow code part. Thanks.
That name leads nowhere.
@doghouch or @PieNotEvenEaten would be better.
Thank you. It's changed now.
@jsg Edited.
Thanks a lot. I'm very serious about being fair in my reviews and I would have hated to have something negative and false in my review. Thank you!
@jsg Thank you for the test.
To make it clear for everyone can you please specify your test parameters - your "targets" file for this test and download file size (I believe you are not testing speed with default 64MB file)
First, the "final" result for a target is based on downloading 64 MB (from a 100+ MB test file). Additionally though vpsbench also takes the time for 100KB, 1MB, 10MB. This has some technical reasons, one of which is that insight can be gained from looking at those values. The final size of 64 MB has been chosen because there's very little, if any, change beyond 64 MB and I don't want vpsbench to waste traffic volume.
Here are the target files:
http://speedtest.mel01.softlayer.com/downloads/test100.zip AU,MEL:
http://speedtest.che01.softlayer.com/downloads/test100.zip IN,CHE:
http://speedtest.lon02.softlayer.com/downloads/test100.zip UK,LON:
http://speedtest.fra02.softlayer.com/downloads/test100.zip DE,FRA:
http://speedtest.mil01.softlayer.com/downloads/test100.zip IT,MIL:
http://speedtest.par01.softlayer.com/downloads/test100.zip FR,PAR:
http://lg-ro.vps2day.com/100MB.test RO,BUC:
http://speedtest.ftp.otenet.gr/files/test100Mb.db GR,UNK:
http://93.95.100.190/test100mb.bin RU,MOS:
http://speedtest.dal05.softlayer.com/downloads/test100.zip US,DAL:
http://speedtest.sjc01.softlayer.com/downloads/test100.zip US,SJC:
http://speedtest.wdc01.softlayer.com/downloads/test100.zip US,WDC:
http://speedtest.sao01.softlayer.com/downloads/test100.zip BR,SAO:
http://speedtest.tokyo.linode.com/100MB-tokyo.bin JP,TOK:
http://speedtest.osl01.softlayer.com/downloads/test100.zip NO,OSL:
Except for the RO, BUC one (which since a while seems to be flaky) those targets have served me well but it's very simple to change them, add new ones, etc. The target file is a simple text file and a commented example comes with vpsbench.
@jsg
I'm pretty sure that this server can't handle even 100 mbps because from 4 different locations ( 3 in Russian Federation, 1 in Latvia and 1 in Ukraine ) I can get only 10 mbps.
That's quite possible and I'll gladly use another Moscow target if I'm recommended a good one.
If you can tell me a better Moscow target and if you want that (and provide access for a day or two to me) I'll gladly run vpsbench again and publish the hopefully then more realistic results here.
I find that 100mb gives the connection time to ramp up to speed, which isn't a good indicator for smaller files. If it's a web server there will be basically no 100mb files being served.
100MB is useless imho.
1GB+ is way more useful.
1TB+ for die hards
Keep in mind what this is about! It's a benchmark that is, it's meant to provide a good overview of a system - and it can not possibly match all use cases.
But I did indeed make the vpsbench network tests more elaborate than most others and provide also values for 100 KB, 1MB, and 10MB to allow a more detailled glimpse.
Also I was actually thinking about small chunks, too, say 1 KB and 10 KB. The problem though is that those measurements tend to tell you more about a lot of things than about connectivity, simply because of (a) my timer resolution of 1 musec (which already is way, way better than most benchmarks) and (b) the short data blips. All in all those values would not provide any insight of value and would hardly be tenable. Example: When just at the very same time anyone on that node happened to do something a bit more demanding (say writing 1 KB to a file) that would dramatically increase the "noise" level of the measurements.
Finally I also didn't want to be too dependant on hop timings, target server performance, etc.
TL;DR fine measurement granularity is great but too much of it creates a signal vs. noise problem ~ worthless data points.
Yes.
Nice review, seems honest!
Using too many softlayer could have an impact on the results if their network is saturated somewhere "early" (as all tests will likely take the same route to the US east coast for all NA/SA locations).
I'm open to suggestions re better network targets. Also note that everyone can - easily - create and use his own target files with his own choice of target servers.
@jsg We have no suggestion for a one simple reason: all locations for such testing should pe properly monitored so you can give rating for the hosting company. Also, 64MB seems is not enought to give rating about uplink quality, it's better to use atleast 200-300MB.
Our benchmark is seems pretty fair for 100 Mbit/s and location in Russian Federation (except your speedtest to another Russian location. Thanks.
Of course my benchmark is fair. I put a lot of effort into being fair.
As for your other point I disagree. Unlike most who are opinion based I actually did lots of testing and 64 MB is plenty enough.
Two points to keep in mind:
(a) measurement deviation. Networks (as well as networking equipment, btw) is not static. Taking the exact same measurement between A and B many times over a day (or worse a month) will lead to different results; usually just slight differences below 1% but occasionally more significant ones. Hence it doesn't make sense to hunt for accuracy beyond the natural measurement deviation.
(b) the benchmark does not aim to answer the question "How many bytes - exactly - can you transfer between the benchmarked host and some targets?". In fact such an attempt would be nonsensical in any non trivial and fully controlled network situation (see (a) above).
What a benchmark can provide and what vpsbench does provide is a quite well comparable, and repeatable "better than a ballpark number but less than accurate number".
Plus, again, vpsbench allows to (very simply) create and use ones own set of preferred targets. For me (in western Europe), for example, a single Moscow target set for Russia is good enough and a second one in St. Petersburg would be "luxurious". For someone living in Russia on the other hand it would probably be desirable to additionally test at a minimum Khabarovsk, Novosibirsk, Omsk. Jekaterinburg, Ufa, Volgograd, Rostov, ...
And with vpsbench you can do that.