All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Free VDS on Verasel dedi benchmark and review
Sadly my VDS giveaway thread has been closed (btw. I still haven't been informed about the reason), which will make it more cumbersome for me and, particularly sadly, hard or impossible for most LET users to get one at all.
But of bloody course I wanted to know how those VDS are performing. So I benchmarked one, my first test VDS which however has almost exactly the same config as the ones I intend to give out for free (4 vCores, 8 GB mem., 50 GB SSD + 300 or 350 GB storage drive).
Here's the benchmark results, based on a bit over 25 runs, and a "review", in "" because, well I am "the provider"; that said I approached both the benchmarking and the review just like I always do. The only difference is or might be (I didn't decide yet and don't want to unless really required) that this VDS has no network limitations, but to be perfectly honest, my main focus in that regard wasn't the VDS but the node connectivity, so your results may be somewhat worse.
Let's start with sysinfo, processor, and memory.
Version 2.5.0a, (c) 2018+ jsg (->lowendtalk.com)
Machine: amd64, Arch.: amd64, Model: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
OS, version: FreeBSD 14.2, Mem.: 7.989 GB
CPU - Cores: 4, Family/Model/Stepping: 6/63/2
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 htt sse3 pclmulqdq vmx ssse3 fma
cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline aes
xsave osxsave avx f16c rdrnd hypervisor
Ext. Flags: fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid fpcsds umip
syscall nx pdpe1gb rdtscp lm lahf_lm lzcnt
AES? Yes
Nested Virt.? Yes
HW RNG? Yes
ProcMem SC [MB/s]: avg 159.5 - min 52.7 (33.0 %), max 264.2 (165.7 %)
ProcMem MA [MB/s]: avg 607.0 - min 550.2 (90.7 %), max 667.5 (110.0 %)
ProcMem MB [MB/s]: avg 652.2 - min 579.2 (88.8 %), max 859.1 (131.7 %)
ProcMem AES [MB/s]: avg 507.5 - min 501.8 (98.9 %), max 508.9 (100.3 %)
ProcMem RSA [kp/s]: avg 55.1 - min 52.7 (95.6 %), max 57.3 (103.9 %)
I'm a bit torn between "meeh" and "hey, not bad!". "meeh" because, well, the node is a Xeon E5v3 and that shows (unpleasantly). And "hey, not bad!" because the multi-core results not only aren't bad but also show really low spread, which one should expect from a VDS with truly dedicated vCores, i.e. no shared or non-exclusive BS as with many providers.
Now, on to the (main, SSD) disk...
--- Disk 4 KB - Buffered ---
Write seq. [MB/s]: avg 6.51 - min 6.15 (94.4%), max 6.72 (103.2%)
Write rnd. [MB/s]: avg 6.74 - min 6.25 (92.7%), max 7.04 (104.4%)
Read seq. [MB/s]: avg 52.39 - min 44.42 (84.8%), max 55.29 (105.5%)
Read rnd. [MB/s]: avg 46.80 - min 38.95 (83.2%), max 48.85 (104.4%)
--- Disk 4 KB - Sync/Direct ---
Write seq. [MB/s]: avg 6.57 - min 6.33 (96.3%), max 6.75 (102.7%)
Write rnd. [MB/s]: avg 6.80 - min 6.40 (94.2%), max 7.06 (103.9%)
Read seq. [MB/s]: avg 54.43 - min 51.78 (95.1%), max 55.88 (102.7%)
Read rnd. [MB/s]: avg 47.39 - min 43.85 (92.5%), max 49.87 (105.2%)
--- Disk 64 KB - Buffered ---
Write seq. [MB/s]: avg 46.31 - min 34.14 (73.7%), max 48.06 (103.8%)
Write rnd. [MB/s]: avg 61.94 - min 58.40 (94.3%), max 63.43 (102.4%)
Read seq. [MB/s]: avg 1984.78 - min 1895.44 (95.5%), max 2057.21 (103.6%)
Read rnd. [MB/s]: avg 514.38 - min 438.77 (85.3%), max 548.71 (106.7%)
--- Disk 64 KB - Sync/Direct ---
Write seq. [MB/s]: avg 10.08 - min 9.93 (98.6%), max 10.22 (101.4%)
Write rnd. [MB/s]: avg 5.54 - min 5.43 (97.9%), max 5.64 (101.7%)
Read seq. [MB/s]: avg 1941.87 - min 1642.53 (84.6%), max 2044.59 (105.3%)
Read rnd. [MB/s]: avg 525.29 - min 457.30 (87.1%), max 555.23 (105.7%)
--- Disk 1 MB - Buffered ---
Write seq. [MB/s]: avg 57.86 - min 44.30 (76.6%), max 60.15 (104.0%)
Write rnd. [MB/s]: avg 121.91 - min 115.66 (94.9%), max 124.70 (102.3%)
Read seq. [MB/s]: avg 2732.05 - min 2579.95 (94.4%), max 2822.77 (103.3%)
Read rnd. [MB/s]: avg 1409.31 - min 1091.18 (77.4%), max 1515.39 (107.5%)
--- Disk 1 MB - Sync/Direct ---
Write seq. [MB/s]: avg 24.95 - min 24.67 (98.9%), max 25.18 (100.9%)
Write rnd. [MB/s]: avg 18.41 - min 18.29 (99.4%), max 18.50 (100.5%)
Read seq. [MB/s]: avg 2739.82 - min 2596.35 (94.8%), max 2839.13 (103.6%)
Read rnd. [MB/s]: avg 1437.16 - min 1323.03 (92.1%), max 1484.97 (103.3%)
--- Disk IOps (Sync/Direct) ---
Write seq. [MB/s]: avg 12.16 - min 11.19 (92.0%), max 12.33 (101.4%)
IOps : avg 3112.56 - min 2863.78 (92.0%), max 3156.77 (101.4%)
Hmm, also not really great but clearly in well usable terrain. For a SSD (not NVMe) > 10 MB/s and > 3k IOps are quite decent. Plus, of course remember: this is a free VDS!
But now comes the cherry on top, connectivity.
--- Europe ---
NO OSL mirror.terrahost.no [F: 0]
DL [Mb/s]: avg 590.3 - min 428.9 (72.7%), max 737.2 (124.9%)
Ping [ms]: avg 18.0 - min 17.9 (99.7%), max 18.9 (105.3%)
Web ping [ms]: avg 19.4 - min 17.9 (92.4%), max 38.3 (197.7%)
UK LON lon.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 1315.8 - min 1094.9 (83.2%), max 1430.1 (108.7%)
Ping [ms]: avg 8.0 - min 7.9 (98.7%), max 10.3 (128.7%)
Web ping [ms]: avg 8.0 - min 7.9 (98.5%), max 10.3 (128.4%)
NL AMS mirrors.xtom.nl [F: 0]
DL [Mb/s]: avg 2710.6 - min 1109.6 (40.9%), max 3642.7 (134.4%)
Ping [ms]: avg 2.5 - min 2.4 (96.3%), max 2.5 (100.3%)
Web ping [ms]: avg 2.9 - min 2.6 (91.1%), max 3.2 (112.1%)
DE FRA fra.lg.core-backbone.com [F: 0]
DL [Mb/s]: avg 1392.9 - min 1348.2 (96.8%), max 1470.6 (105.6%)
Ping [ms]: avg 7.1 - min 0.0 (0.0%), max 7.5 (105.6%)
Web ping [ms]: avg 7.2 - min 0.0 (0.0%), max 7.7 (107.0%)
FR PAR mirror.in2p3.fr [F: 0]
DL [Mb/s]: avg 487.6 - min 317.1 (65.0%), max 542.0 (111.2%)
Ping [ms]: avg 19.7 - min 19.7 (100.0%), max 19.7 (100.0%)
Web ping [ms]: avg 61.6 - min 20.0 (32.4%), max 191.1 (310.0%)
CH ZUR mirror.init7.net [F: 0]
DL [Mb/s]: avg 752.5 - min 707.2 (94.0%), max 768.7 (102.2%)
Ping [ms]: avg 14.5 - min 14.5 (99.9%), max 14.6 (100.6%)
Web ping [ms]: avg 16.4 - min 14.6 (89.3%), max 18.9 (115.5%)
IT MIL it1.mirror.vhosting-it.com [F: 0]
DL [Mb/s]: avg 668.2 - min 631.8 (94.6%), max 695.2 (104.0%)
Ping [ms]: avg 15.9 - min 15.8 (99.6%), max 16.0 (100.8%)
Web ping [ms]: avg 17.9 - min 16.0 (89.5%), max 40.1 (224.3%)
ES MAD mirror.raiolanetworks.com [F: 0]
DL [Mb/s]: avg 413.0 - min 405.8 (98.3%), max 419.7 (101.6%)
Ping [ms]: avg 26.5 - min 26.5 (100.0%), max 26.7 (100.7%)
Web ping [ms]: avg 28.2 - min 26.8 (95.0%), max 29.3 (103.9%)
RO BUC almalinux.mirrors.orange.ro [F: 0]
DL [Mb/s]: avg 313.6 - min 288.4 (92.0%), max 340.7 (108.7%)
Ping [ms]: avg 35.8 - min 35.7 (99.8%), max 35.8 (100.0%)
Web ping [ms]: avg 43.7 - min 35.8 (82.0%), max 119.8 (274.3%)
RU MOS mirror.yandex.ru [F: 0]
DL [Mb/s]: avg 231.5 - min 109.6 (47.3%), max 256.2 (110.7%)
Ping [ms]: avg 43.8 - min 43.7 (99.7%), max 46.1 (105.1%)
Web ping [ms]: avg 118.7 - min 43.8 (36.9%), max 787.3 (663.2%)
--- Asia / Oceania ---
RU SIB mirror.truenetwork.ru [F: 0]
DL [Mb/s]: avg 117.9 - min 99.5 (84.4%), max 122.6 (104.0%)
Ping [ms]: avg 94.4 - min 93.5 (99.1%), max 114.2 (121.0%)
Web ping [ms]: avg 100.1 - min 93.5 (93.4%), max 143.4 (143.2%)
IR SHI ir.almalinux.sindad.cloud [F: 0]
DL [Mb/s]: avg 130.6 - min 120.3 (92.1%), max 140.4 (107.5%)
Ping [ms]: avg 86.6 - min 85.9 (99.2%), max 89.0 (102.8%)
Web ping [ms]: avg 105.1 - min 86.2 (82.0%), max 570.2 (542.7%)
IN MUM mirrors.piconets.webwerks.in [F: 0]
DL [Mb/s]: avg 90.2 - min 80.2 (88.9%), max 95.5 (105.9%)
Ping [ms]: avg 122.4 - min 120.5 (98.4%), max 140.4 (114.7%)
Web ping [ms]: avg 126.0 - min 120.5 (95.6%), max 141.2 (112.1%)
SG SGP mirror.sg.gs [F: 0]
DL [Mb/s]: avg 69.4 - min 68.0 (97.9%), max 71.0 (102.3%)
Ping [ms]: avg 159.3 - min 159.3 (100.0%), max 159.7 (100.2%)
Web ping [ms]: avg 163.2 - min 160.5 (98.3%), max 171.1 (104.8%)
CN HKG mirrors.xtom.hk [F: 0]
DL [Mb/s]: avg 55.4 - min 52.8 (95.3%), max 58.7 (105.9%)
Ping [ms]: avg 199.3 - min 0.0 (0.0%), max 225.5 (113.2%)
Web ping [ms]: avg 204.0 - min 0.0 (0.0%), max 299.9 (147.0%)
CN BEJ mirrors.huaweicloud.com [F: 2]
DL [Mb/s]: avg 41.6 - min 0.0 (0.0%), max 62.2 (149.4%)
Ping [ms]: avg 224.5 - min 0.0 (0.0%), max 287.2 (127.9%)
Web ping [ms]: avg 329.4 - min 0.0 (0.0%), max 1267.3 (384.8%)
JP OSA mirrors.xtom.jp [F: 0]
DL [Mb/s]: avg 40.3 - min 38.4 (95.3%), max 47.9 (118.8%)
Ping [ms]: avg 280.1 - min 247.6 (88.4%), max 281.3 (100.4%)
Web ping [ms]: avg 280.3 - min 247.6 (88.3%), max 283.9 (101.3%)
AU SYD mirrors.xtom.au [F: 0]
DL [Mb/s]: avg 43.4 - min 41.4 (95.4%), max 45.5 (104.8%)
Ping [ms]: avg 261.1 - min 260.8 (99.9%), max 261.3 (100.1%)
Web ping [ms]: avg 261.3 - min 260.8 (99.8%), max 262.1 (100.3%)
--- Africa ---
KE NAI mirror.liquidtelecom.com [F: 0]
DL [Mb/s]: avg 74.5 - min 73.3 (98.4%), max 76.1 (102.2%)
Ping [ms]: avg 147.2 - min 147.0 (99.9%), max 147.4 (100.1%)
Web ping [ms]: avg 148.4 - min 147.1 (99.1%), max 149.9 (101.0%)
ZA WEC archlinux.za.mirror.allworldit.com [F: 0]
DL [Mb/s]: avg 62.3 - min 58.6 (94.0%), max 68.5 (110.0%)
Ping [ms]: avg 164.6 - min 164.0 (99.6%), max 177.5 (107.8%)
Web ping [ms]: avg 188.2 - min 166.8 (88.6%), max 222.5 (118.2%)
MU POL archlinux-mirror.cloud.mu [F: 0]
DL [Mb/s]: avg 52.1 - min 51.1 (98.1%), max 52.8 (101.4%)
Ping [ms]: avg 219.2 - min 219.0 (99.9%), max 219.9 (100.3%)
Web ping [ms]: avg 222.5 - min 219.0 (98.4%), max 272.2 (122.3%)
--- America ---
CA MTL speedtest.mtl2.ca.leaseweb.net [F: 0]
DL [Mb/s]: avg 136.4 - min 132.5 (97.2%), max 139.1 (102.0%)
Ping [ms]: avg 85.3 - min 83.4 (97.7%), max 123.8 (145.1%)
Web ping [ms]: avg 85.4 - min 83.5 (97.8%), max 123.8 (145.0%)
US NYC mirrors-nyj.hawkhost.com [F: 0]
DL [Mb/s]: avg 146.0 - min 143.5 (98.3%), max 149.7 (102.6%)
Ping [ms]: avg 75.3 - min 75.2 (99.9%), max 75.3 (100.0%)
Web ping [ms]: avg 75.9 - min 75.2 (99.1%), max 79.3 (104.5%)
US ASH ash.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 124.5 - min 112.6 (90.5%), max 136.2 (109.4%)
Ping [ms]: avg 89.5 - min 89.4 (99.9%), max 89.8 (100.3%)
Web ping [ms]: avg 91.6 - min 89.4 (97.6%), max 97.8 (106.8%)
US WDC speedtest.wdc2.us.leaseweb.net [F: 0]
DL [Mb/s]: avg 105.3 - min 38.8 (36.9%), max 138.1 (131.2%)
Ping [ms]: avg 79.4 - min 79.3 (99.9%), max 79.6 (100.3%)
Web ping [ms]: avg 83.4 - min 79.5 (95.4%), max 85.3 (102.3%)
US PIB mirror.pit.teraswitch.com [F: 0]
DL [Mb/s]: avg 126.9 - min 114.3 (90.1%), max 132.4 (104.3%)
Ping [ms]: avg 89.2 - min 87.6 (98.2%), max 129.3 (145.0%)
Web ping [ms]: avg 89.8 - min 87.6 (97.5%), max 129.3 (143.9%)
US MIA speedtest.mia11.us.leaseweb.net [F: 0]
DL [Mb/s]: avg 105.3 - min 102.3 (97.1%), max 108.3 (102.8%)
Ping [ms]: avg 105.5 - min 105.3 (99.8%), max 105.6 (100.1%)
Web ping [ms]: avg 106.8 - min 105.4 (98.7%), max 108.9 (102.0%)
US CHI speedtest.chi11.us.leaseweb.net [F: 0]
DL [Mb/s]: avg 122.2 - min 121.0 (99.1%), max 124.2 (101.7%)
Ping [ms]: avg 91.0 - min 90.8 (99.8%), max 91.2 (100.2%)
Web ping [ms]: avg 91.1 - min 90.8 (99.6%), max 91.6 (100.5%)
US ATL atl.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 111.4 - min 104.4 (93.7%), max 115.6 (103.7%)
Ping [ms]: avg 101.2 - min 100.3 (99.1%), max 105.0 (103.8%)
Web ping [ms]: avg 101.5 - min 100.3 (98.8%), max 106.7 (105.1%)
US PHO phx.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 82.3 - min 81.4 (98.9%), max 82.8 (100.7%)
Ping [ms]: avg 135.2 - min 135.0 (99.8%), max 137.7 (101.8%)
Web ping [ms]: avg 136.0 - min 135.0 (99.3%), max 143.6 (105.6%)
US PTL mirrors.cat.pdx.edu [F: 0]
DL [Mb/s]: avg 85.1 - min 83.8 (98.5%), max 86.8 (102.0%)
Ping [ms]: avg 131.8 - min 131.6 (99.8%), max 132.2 (100.3%)
Web ping [ms]: avg 134.0 - min 131.7 (98.3%), max 146.5 (109.3%)
US LAX mirror.alma.lax1.serverforge.org [F: 0]
DL [Mb/s]: avg 87.3 - min 86.0 (98.5%), max 88.6 (101.5%)
Ping [ms]: avg 128.3 - min 127.7 (99.5%), max 132.6 (103.3%)
Web ping [ms]: avg 130.6 - min 128.0 (98.0%), max 144.2 (110.4%)
US SJO mirrors.xtom.us [F: 0]
DL [Mb/s]: avg 77.2 - min 68.9 (89.3%), max 81.8 (106.0%)
Ping [ms]: avg 141.2 - min 139.6 (98.9%), max 182.3 (129.1%)
Web ping [ms]: avg 145.3 - min 139.6 (96.1%), max 182.3 (125.5%)
US SEA speedtest.sea11.us.leaseweb.net [F: 0]
DL [Mb/s]: avg 86.1 - min 84.5 (98.1%), max 88.3 (102.6%)
Ping [ms]: avg 131.2 - min 131.0 (99.8%), max 131.3 (100.1%)
Web ping [ms]: avg 131.4 - min 131.0 (99.7%), max 131.7 (100.3%)
BR SPA mirrors.ic.unicamp.br [F: 1]
DL [Mb/s]: avg 52.0 - min 0.0 (0.0%), max 55.4 (106.6%)
Ping [ms]: avg 207.9 - min 207.8 (100.0%), max 207.9 (100.0%)
Web ping [ms]: avg 210.4 - min 207.8 (98.8%), max 219.2 (104.2%)
CL SAN elmirror.cl [F: 3]
DL [Mb/s]: avg 38.6 - min 0.0 (0.0%), max 53.5 (138.4%)
Ping [ms]: avg 214.5 - min 213.5 (99.6%), max 214.9 (100.2%)
Web ping [ms]: avg 240.7 - min 213.5 (88.7%), max 748.3 (310.8%)
As usual I'll split it into continents/regions.
Europe - Very nice indeed! Multiple Gb/s results, plenty locations above 500 Mb/s, and even quite remote locations like Moscow showing almost 250 Mb/s.
And one major reason is somewhat uncommon - but good - routing using multiple and diverse carriers, most quite good. IMO @Verasel (or his network guy) really did a very good job there plus use lots of and good peering.
In short: as a Europe centric person I hardly could be more pleased and I very much like what I see.
Asia / Oceania - Also quite decent About 90 Mb/s to webwerks India and about 70 Mb/s to Singapore, and still 55 Mb/s to HongKong aren't results I often see. Also positive, all China and Ozzyland targets were reached and the latter even have similar results, nice!
Africa - Another very positive surprise! The "worst" results here are what I'm used to see as the best results from quite many providers and over 70 Mb/s to KE, Nairobi is something not often seen. Very well done, again.
America - Except for a few exceptions like WDC Leaseweb really decent results as well. Hey, 140+ Mb/s to NYC, about 135 Mb/s to Montreal, 120+ Mb/s to Chicago, and about 85 Mb/s to LAX and to Seattle isn't bad at all. And again: routing. I mostly saw twelve99, GSL, RETN, zayo across the Atlantic and very few HE, Cogent and the likes.
And about 50 Mb/s and close to 40 Mb/s to the Brazil and Chile aren't poor either.
TL;DR There you have it, a somewhat old-ish and mediocre processor, but with dedicated vCores, a not at all shabby SSD, and really good global and particularly good intra-Europe connectivity. I'd be willing to pay €2 or €2.50 per month without thinking long for such a VDS because, yes, the processor certainly isn't a speed daemon but I/you get 4 dedicated vCores, a generous amount of memory, a reasonable SSD size - and we can use it 24/7. Try to get that even for €50 per year! That's why I'd take it in a second for 25 to 30 Euros per year.
Important note to avoid confusion: I mentioned € numbers only to put that thing in a frame. But I do not want a single € or $ from the LET members to whom I'll provide such a VDS!
Finally: two follow up benchmarks (disk only) will follow, if this thread stays alive, both re the storage drive, one Raid card based and one ZFS based.
Comments
@plumberg @OnePrice
Thanks for helping me.
I'm surprised after the whole Verasel thread where he whines about wanting special treatment not to submit a ticket to do a giveaway, that jsg would submit the ticket to LET, LET approves the giveaway and yet they still close the thread without updating the ticket that authorized the giveaway. At least I'd ask in the ticket why they did that.
Also, this will be the closest time people will finally be able to compare jsg benchmarks with yabs and jsg can tout how much better his benchmark results are over yabs reports.
Still waiting for my Devuan VDS🙂
I thought Some mod quoted in that giveaway thread - That prior approval is required by opening a ticket via helpdesk for any member planning to run a giveaway... Else that thread could be deleted ... I believe that may be the reason... Unless @jsg got the approval & still it was deleted.. @jsg Please correct me if I am wrong..
Glad to help!
pretty sure he said in the deleted thread he didn't create a ticket, and @angstrom commented that everyone who wanted to do a giveaway needed to do so shortly before the thread disappeared.
I'm too dumb to understand what's happening here.
Yeah, I was just trying to point out how the whole reason he got the server in the first place was in a 12 page thread where Verasel rage quits after not getting special treatment for not submitting a ticket to do a giveaway. And it's not like he missed the thread, he actively posted in it.
crosses fingers for repeat rage quit
But you know me, I'm always pointing out someone's stubbornness and inability to educate himself. This was just too on the nose.
the i-got-free-stuff review
after 13 pages and if you still expecting a reason then you must either be dumb or blind
Text is white with yellow background cant read results
The way I understood it private users (!= provider) don't need to apply. After all, unlike a provider I have nothing to gain. At all. No penny, no additional revenue, whatever.
The reason why I wanted to share the free dedi I got simply was that I tick(ed) in "we, community!" and not in "I! me! me!"
To make really sure that my thread wasn't misunderstood as lack of respect (incl. for rules) I clearly stated in the last paragraph that if what I did was somehow not OK I'd be perfectly willing to constructively adapt.
I did not even get told the reason for closing or deleting my thread! Not even that.
So, what was achieved? I've lost my trust in the admins here and definitely will never again offer anything for free here. Lesson learned.
Provider XYZ serially running shit shows of threads with loads and loads of invited spam up to the point that the thread is hardly worth reading, or more correctly, wading through lots and lots of bot-like copy-paste spam so as to hopefully find an occasional real human comment - fine, no problem.
But simply sharing a server one got for free without going through nonsensical loops? - Nope, no way, can't be tolerated! Where would we end if normal users gave away anything really for free just like that and without permission? Nope, verboten!
Funny thing is that I even tried to send a ticket to apply (after the thread was closed) and it fucking didn't work! My perfectly valid and working fine email address wasn't accepted and I got stubbornly asked to enter an email address - while right beneath that small fly-over box there was a valid and working email address filled in. And yes, I also tried the game with another, very common, and up-to-date browser. Still no luck.
Nuh, fuck it. I'll give away some of the 10 free VDS I planned to give away (if I can,(the ones I already basically "committed to") but that's it . Tough luck for all the others, I'm sorry, I wanted, really honestly wanted to give them away for free, but I'm not willing to bend over backwards to be "generously" allowed to publicly offer these free VDS.
Also, please do not discuss that any further. ONLY about the benchmark and "review"! Because that seems to be OK without formally applying for it with the other side largely incommunicado. Maybe if I had paid $200 it would have been easier ...
And now ladies and gentlemen, as I said, I have more than enough of those "you will blindly obey and rules mean whatever we please them to mean!" games. Even if I did something wrong from decent human beings I'd have expected at the very least an explanation/reason and a bridge to walk towards their will. With hundreds of hours of work put in (and well noted, I was asked for that by @jbiloh) I should have deserved some slack and friendly "come on, we'll guide you through it".
The (rather few) jsg haters can rejoice.
Fits you! But don't hold your breath, asshole.
You obviously never look into a mirror ...
QQ too long
when quit for rejoice?
Must be something with your browser settings I guess. It's black on yellow background.
Have a nice weekend everyone.
Write performance looks quite bad, assuming there is nothing else going on. Do you have numbers taken directly at the hypervisor for comparison?
How did you virtualize/provision that disk?
Differences in performance can change a lot over a multitude of things like drivers, stripe size, preallocation and so on.
Things I suggest to try when talking about VDS are obviously running high loads in other VMs while benching an empty one.
Use different 'neighbour' workloads like high IOps or high cpu. Eventually run stuff that highly depends on something like L2 cache to see how real dedication vs shared works.
Welcome to start looking at VPS performance from the other side!
PS: any yabs? 😜
ACK, I agree but there's 2 big fat BUTs:
(a) I'm not a provider and I have very limited experience with linux as a VM node nor with virtualization on linux, mainly because I do all those things on BSD since years; but FreeBSD doesn't install on that box (a known problem). Plus of course it's not a box on my table but a remote server with only IPMI to use wrt the server.
So I had to make a choice, either fiddle about with many BIOS settings and other "screws" -or- use linux. I also met the sister of that choice in another regard: I could either try to optimize for speed -or- I could go for provisioning VDSs soon. I picked the latter (within about one week), also for another reason, see point (b).
Also keep in mind that we're talking about free VMs and on one hand I don't have to have VMs that out-compete others and on the other hand my basic plan was to "go back to the basic original idea" that is, to simply make "portions" of a large dedi available.
(b) it seems that dedi is quite old. The hardware was quite nice back then and @Verasel didn't go for cheap, don't get me wrong, he put good stuff (back then) into that box, for example SAS which is more professional and better than SATA, plus even SAS-12 which was kind of high-end and really fast back then, plus he also put enterprise grade drives in, and quite some other really fast and nice (back then). But still it's an old box and no matter how much effort I put into optimizing it, it still would look lame next to not even a Ryzen but say, a Xeon Scalable with even just mediocre NVMes.
So, I chose differently and I think adequate by focusing on safety, e.g. mirroring all drives. I don't really expect any of the drives to die within the year I have that server, but hey, there will be some people hosted on that box and I'm not willing to risk their data; I want to provide reliable and safe VMs albeit not exactly fast ones by any stretch.
Plus again I was forced to use an OS with which I have little experience as a server OS (but of course know as I use it on my desktop) and a hypervisor I only know to a limited extent because I never needed or used it because I prefer - and know quite well - BSD which IMO is a way better choice anyway except for a few mainly desktop niches like the one that made me use linux on my desktop.
Whatever, we're talking about a gift here, about 100% free VDSs and I for one am very happy about the old box Verasel so generously provided 100% free. So I see no reason at all to complain about anything, quite the contrary, I see a reason for joy. It wouldn't and didn't cross my mind to ask Verasel to put some faster devices into that box. No sir, that's not how I tick. And if I want speed daemons I have a few of those (both in my lab and in DCs) and/or I'll pay up.
And YES, I do expect to see lower performance numbers once a couple of those VDSs are out and in use. My benchmark above was done on one VDS just like those I'm giving away, not on the dedi itself, but yes, since so far there only is a single VDS the numbers I provided are somewhat optimistic, but well, I can only benchmark what I have.
Btw if anyone now shrugs and turns away due to the not exactly impressive results that actually is not bad in my eyes but quite healthy and not unintended. I wanted potential users to see and know or at least have a realistic idea of what they'll get. That's the main reason why I published this benchmark.
And finally, YES again, when I do requested testing a new (as in "different from what we have and know inside out") node for a provider or a significantly different config aka "trying something different and hopefully faster/better" I usually ask them to create and provide 5 or 10 extra VMS as "background load" as I call it so as to simulate an at least halfway occupied node aka getting realistic data.
But (a) I could not (yet) do that in this case, and (b) why should I anyway on an old box I got for free and share (most of it) with others also for free?
But of course I will occasionally benchmark my personal VDS from time to time. It would be quite strange if a benchmarker hid his own server numbers, wouldn't it?
No need to apologize for anything.
I was just curious if the speeds are better directly on the hostnode and trying to give some pointers about improving the setup to make the most out of it.
Wasn't meant in any way to criticize the server as such...
Well, you did the irrational rage bit, time for the quit half.
You did that wrong, SMH. Your insults are even wrong.
I didn't apologize and have no reason to. I simply explained my view and why I did it the way I did and do.
As for testing the node itself, I'd like to of course, but again: the time used for that is time I don't have to get the VDSs ready and out to the users and I strongly dislike to keep them waiting.
no yabs no review
13 "but"s and the multiple mentioning of it being "free" and "old" made it sound much like an apology - at least what I received from it ;-)
take your time and either provide some more data later on or not, fully up to you ofc.
just always curious and find it useful to be able to compare performance in a VM with what is possible without the virtualization layer, that's all.
Industry standard is yabs.
LET != the industry.
Here we go again. The Russian cunt is pretending not to understand the rules ...
and has posted another giveaway thread disguised as a review.
@angstrom, bend over and pin this thread to the top of the front page.
LET/LES/WHT is the industry. You may deny, but people spoke their word and standard is set.
I am not sure why LET is not nice to you guys trying to contribute to community by providing free resources.
You may build an open project for your free vds for qulified users.
Just keep your passion, bro.
im sure rules are there for reasons but im also fucking sure a 4 month old account wouldnt be able to understand that
keep sucking up, bro.