All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Triple NexusBytes review UK, SGP, JP
As I've said in my last review @seriesn provided me with a full month access to two nodes, UK and SGP and a bit later he added access to his (new it seems) Japan/Tokyo node for a normal 3 day test.
Here are the results for the SGP node:
Machine: amd64, Arch.: amd64, Model: AMD Ryzen 9 3900X 12-Core Processor
OS, version: FreeBSD 12.0, Mem.: 1.985 GB
CPU - Cores: 2, Family/Model/Stepping: 23/113/0
Cache: 32K/32K L1d/L1i, 512K L2, 64M 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 sse3 pclmulqdq ssse3 fma cx16 sse4_1
sse4_2 popcnt aes xsave osxsave avx f16c rdrnd hypervisor
Ext. Flags: fsgsbase bmi1 avx2 smep bmi2 syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm lahf_lm cmp_legacy svm cr8_legacy lzcnt sse4a misalignsse
3dnowprefetch osvw
ProcMem SC: avg 383.9 - min 331.4 (86.3 %), max 440.9 (114.9 %)
ProcMem MC: avg 845.9 - min 769.6 (91.0 %), max 954.9 (112.9 %)
--- Disk - Buffered ---
Write seq.: avg 1291.70 - min 718.89 (55.7%), max 1613.92 (124.9%)
Write rnd.: avg 6025.82 - min 4298.97 (71.3%), max 8615.83 (143.0%)
Read seq.: avg 1270.81 - min 1113.02 (87.6%), max 1665.00 (131.0%)
Read rnd.: avg 5372.93 - min 3989.73 (74.3%), max 6804.24 (126.6%)
--- Disk - Sync/Direct ---
Write seq.: avg 116.86 - min 88.82 (76.0%), max 145.86 (124.8%)
Write rnd.: avg 217.56 - min 90.01 (41.4%), max 264.93 (121.8%)
Read seq.: avg 2894.63 - min 2239.15 (77.4%), max 4338.47 (149.9%)
Read rnd.: avg 513.16 - min 401.53 (78.2%), max 634.31 (123.6%)
US LAX lax.download.datapacket.com
DL [Mb/s]: avg 35.83 - min 5.01 (14.0%), max 41.42 (115.6%)
Ping: avg 175.3 - min 164.5 (93.9%), max 221.8 (126.6%)
Web ping: avg 177.9 - min 164.5 (92.5%), max 221.8 (124.7%)
NO OSL speedtest.osl01.softlayer.com
DL [Mb/s]: avg 23.00 - min 17.20 (74.8%), max 24.72 (107.5%)
Ping: avg 259.8 - min 253.6 (97.6%), max 336.7 (129.6%)
Web ping: avg 335.2 - min 253.6 (75.7%), max 2711.4 (809.0%)
US SJC speedtest.sjc01.softlayer.com
DL [Mb/s]: avg 32.89 - min 26.00 (79.0%), max 36.39 (110.6%)
Ping: avg 174.4 - min 115.7 (66.3%), max 180.2 (103.3%)
Web ping: avg 220.5 - min 169.7 (77.0%), max 2766.1 (1254.6%)
JP TOK speedtest.tokyo2.linode.com
DL [Mb/s]: avg 76.02 - min 12.82 (16.9%), max 90.90 (119.6%)
Ping: avg 70.8 - min 70.0 (98.9%), max 109.8 (155.2%)
Web ping: avg 72.6 - min 70.0 (96.5%), max 109.8 (151.3%)
AU MEL speedtest.mel01.softlayer.com
DL [Mb/s]: avg 26.85 - min 0.00 (0.0%), max 30.16 (112.3%) - (http error: -10)
Ping: avg 214.5 - min 139.0 (64.8%), max 311.4 (145.2%)
Web ping: avg 265.3 - min 200.4 (75.5%), max 2311.9 (871.4%)
IT MIL speedtest.mil01.softlayer.com
DL [Mb/s]: avg 33.07 - min 22.16 (67.0%), max 39.06 (118.1%)
Ping: avg 172.7 - min 158.9 (92.0%), max 264.7 (153.3%)
Web ping: avg 204.7 - min 158.9 (77.6%), max 2017.9 (985.6%)
FR PAR speedtest.par01.softlayer.com
DL [Mb/s]: avg 32.90 - min 22.05 (67.0%), max 37.38 (113.6%)
Ping: avg 172.8 - min 109.3 (63.3%), max 251.3 (145.5%)
Web ping: avg 244.0 - min 160.6 (65.8%), max 2537.3 (1039.8%)
SG SGP mirror.sg.leaseweb.net
DL [Mb/s]: avg 910.36 - min 94.73 (10.4%), max 961.64 (105.6%)
Ping: avg 1.3 - min 1.1 (83.2%), max 5.7 (431.0%)
Web ping: avg 1.4 - min 1.2 (87.3%), max 5.7 (414.7%)
BR SAO speedtest.sao01.softlayer.com
DL [Mb/s]: avg 17.36 - min 0.00 (0.0%), max 18.36 (105.7%) - (http error: -10)
Ping: avg 347.7 - min 340.1 (97.8%), max 493.1 (141.8%)
Web ping: avg 410.9 - min 340.7 (82.9%), max 2982.3 (725.8%)
IN CHN speedtest.che01.softlayer.com
DL [Mb/s]: avg 27.66 - min 4.10 (14.8%), max 30.01 (108.5%)
Ping: avg 210.9 - min 207.6 (98.4%), max 254.2 (120.5%)
Web ping: avg 233.7 - min 207.9 (89.0%), max 1627.8 (696.6%)
GR UNK speedtest.ftp.otenet.gr
DL [Mb/s]: avg 23.24 - min 0.00 (0.0%), max 31.75 (136.6%) - (http error: -10)
Ping: avg 13905.6 - min 196.9 (1.4%), max 1398713.1 (10058.6%)
Web ping: avg 13941.5 - min 197.0 (1.4%), max 1398713.1 (10032.8%)
US WDC mirror.wdc1.us.leaseweb.net
DL [Mb/s]: avg 26.52 - min 0.59 (2.2%), max 29.29 (110.4%)
Ping: avg 856.1 - min 220.7 (25.8%), max 215908.3 (25218.7%)
Web ping: avg 860.6 - min 220.8 (25.7%), max 215908.3 (25088.5%)
DE FRA speedtest.fra02.softlayer.com
DL [Mb/s]: avg 33.34 - min 5.38 (16.1%), max 38.66 (115.9%)
Ping: avg 170.1 - min 158.7 (93.3%), max 247.4 (145.4%)
Web ping: avg 224.3 - min 158.8 (70.8%), max 2624.6 (1170.0%)
RU MOS speedtest.hostkey.ru
DL [Mb/s]: avg 31.57 - min 0.00 (0.0%), max 35.98 (114.0%) - (http error: -10)
Ping: avg 200.4 - min 186.1 (92.9%), max 323.3 (161.3%)
Web ping: avg 211.8 - min 186.4 (88.0%), max 343.0 (161.9%)
US DAL speedtest.dal05.softlayer.com
DL [Mb/s]: avg 27.24 - min 23.56 (86.5%), max 29.75 (109.2%)
Ping: avg 213.9 - min 208.0 (97.3%), max 219.0 (102.4%)
Web ping: avg 217.9 - min 208.6 (95.7%), max 1119.9 (513.9%)
UK LON speedtest.lon02.softlayer.com
DL [Mb/s]: avg 32.95 - min 5.78 (17.5%), max 37.62 (114.2%)
Ping: avg 2786.0 - min 164.8 (5.9%), max 1166077.1 (41855.6%)
Web ping: avg 2843.9 - min 164.8 (5.8%), max 1166077.1 (41002.1%)
US NYC nyc.download.datapacket.com
DL [Mb/s]: avg 21.76 - min 0.52 (2.4%), max 30.08 (138.2%)
Ping: avg 229.2 - min 132.5 (57.8%), max 262.7 (114.6%)
Web ping: avg 233.8 - min 220.4 (94.3%), max 485.3 (207.6%)
RO BUC 185.183.99.8
DL [Mb/s]: avg 31.20 - min 2.57 (8.2%), max 37.43 (120.0%)
Ping: avg 2993.2 - min 177.7 (5.9%), max 1248759.8 (41719.3%)
Web ping: avg 3004.6 - min 177.9 (5.9%), max 1248759.8 (41561.7%)
CN_HK mirror.hk.leaseweb.net
DL [Mb/s]: avg 134.05 - min 11.58 (8.6%), max 160.32 (119.6%)
Ping: avg 12069.6 - min 37.4 (0.3%), max 1407793.8 (11663.9%)
Web ping: avg 12069.8 - min 37.4 (0.3%), max 1407793.8 (11663.8%)
First the CPU and memory: It's what one expects from a Zen 2 processor with decent memory and from NexusBytes. Nice, really nice. Also note the low spread which suggests that the node is not crowded.
The disks are decent, too and again, we find that the node isn't crowded although there certainly is some business going on.
Regarding the network I first need to explain something. When you see 'http error: X' (x being -1 or -10) that does not mean that those error always happen or even just frequently. What it means is that they did happen at least once. both -1 and -10 boil down to a receive error, either early on (connection and headers) or during the test file download itself.
First the good news: one does indeed get a 1 Gb/s port as is demonstrated by the test against another SGP target.
As for the rest, oh well ... what doesn't worry me so much is the relatively low download speed all around the globe. After all those are rather cheap VPSs and frankly, for very many use cases 20 or 30 Mb/s is sufficient. What really does worry me is the (lack of) consistency that shows itself in sometimes really extreme numbers like 1.2% min and 40000% max (400 times slower ping) and average ping times in the seconds range rather than milliseconds for quite a few targets.
Now, I don't know that corner of the world well and maybe, even probably they are way less pampered than we are in Europe and North-America, but still those results are nothing to write home about.
I'll end this on a positive node. The download speeds both to Hongkong and Tokyo are quite decent based on what I've seen in that region.
Comments
Next, the UK node:
Front up: I like seriesn/NexusBytes and am a happy customer myself so, frankly I seriously considered to suggest to blow it off and to do the benchmark and review at a later point in time after they tuned some things - but I know seriesn, his response would be (and already was once) "We are transparent. That's one of our principles" ...
The Zen 2 processor and matching memory are great as always. The disk is a bit stressed as it seems to be a well occupied node, but OK. But the network, oh boy ... and here we are not talking about some far off Asian location but about London which certainly is among the best and massively connected locations on this planet.
Just look at the LON softlayer test target. Just shy of 900 Mb/s download speed against a node that might even be in the same colo or, at worst, is connected via multiple short and fat fibers. And a ping of avg. almost half a second and up to 40 or even 50 seconds?! Let me mercifully end this with a positive remark: the latency to Hongkong is quite decent, and the average download speeds are not great for a London node but OK.
Note: both 1 month test results are based on between 400 and 500 benchmark runs. As usual with my benchmarks the runs are randomly timed and around the clock.
Now, to the Japan node. This one is the pleasant surprise, but before I begin I have to apologize for a silly mistake: I forgot to run the '-s' option at the beginning, so there are no data provided for the systems details. I do remember though that the processor was a Ryzen 37xx and the rest was the usual, just with the other tested VPSs (2 GB mem., etc.). Again, my sincere apologies.
Not much to say about the processor and memory. It's what we came to expect from NexusBytes and Zen2. Very nice indeed.
Similarly the disks, obviously NVMes, are within the range of what we expect from NexusBytes.
But the network! Look at those numbers! Nice, really nice. While the download speed to another Tokyo target does not reach a full Gigabit per second it's certainly easily damn good enough. To/from SGP 75 Mb/s and to/from Hongkong even above 100 Mb/s seems remarkable to me and generally download speeds in the 20 to 50 Mb/s range all over the globe are quite OK, too.
But what really pleases me is that everything is largely consistent with well acceptable to nice low spreads, quite OK ping times with OK to nice spreads, really nice.
If you need a decent and decently priced VPS in East Asia with a really decent HongKong (China) connectivity NexusBytes Tokyo VPS certainly should be near the top of your candidates list!
Kudos to seriesn - and a big Thank you both for providing the test VPSs and for being such a straight guy who not just talks about transparency but actually lives it!
@jsg thank you for continuing to invest your time and helping Nexus Bytes
. Your feedbacks are always valuable and helps me see things from a different perspective. Appreciate the honesty and transparency.
You know how I am. Might not get things fixed immediately but I will work on the concerns on the backend and will get back to you once things improves
You've just discovered the difference between mean and median. My guess is that the median ping is somewhere around 1ms but there was one packet that (apparently??) took 218 seconds which makes the mean value soar, but is pretty irrelevant and frankly seems like some other issue with the benchmark.
Feel free to actually write a better benchmark... or actually you might first want to learn how to properly criticize (hint: be specific and provide evidence or clear indicators).
Have a nice day and be sure to update your nick.
Boy, the irony is strong with this one.
Proceeds to make multiple unsubstantiated claims...
...and then mocks for not providing evidence. Lol you can't make this sort of cluelessness up.
The embodiment of someone who walks around believing they are far smarter than they are. Adorable.
How smart can a LET user be if they are a LET user... xD
I fully confirm your self-evaluation with one exception: I don't think your attitude is adorable. Your arrogant first statement in your first post supports my impression.
Followed by "guessing" ...
Indeed, most pings are about 1.4 ms .. but there was a ping that took 218471.8 ms on Sun Sep 6, at 13:39:46 BST, and there were some more out of the normal values spread over the whole testing period. Am I supposed to not include and report that? Am I supposed to offer 95 percentile results?
I run benchmarks and plenty of them - which is a plus. And then I compile all those results and report the best, the worst and the average, which is another plus.
I like @seriesn and I'm certainly not trying to make him look bad - but neither can I try to make him look good. I simply and objectively report what I measured, that is my task. And if there is/are gross and extreme out of range values I report those just as I report particularly good values.
If there is a value that is about 100000 times the normal then there is a problem and I in fact consider it to be a useful service both to the community and to the provider to discover and report such cases.Now seriesn has something concrete in his hands and he can approach his colo or his technicians and ask them why in hell something like that can happen.
I have data from hundreds of benchmark runs - and you? But that wasn't even my point. My point was that your criticism has no value for me because it's based on wild guessing (and arrogance). And my other point was that "criticising" is cheap; in your case even just based on guessing. Designing and building a benchmark on the other hand is a lot of work and requires a lot of research, experience and knowledge. Hell, even just running hundreds of benchmarks is quite a bit of work. In fact I wrote yet another program to automate the runs and to spread them all over the day and running them at unpredictable times (to not induce providers to "optimize" ...). Yet I still need to spend a lot of time to "herd" those testee VPSs and to verify that everything runs smoothly, to download interim result sets, etc.
Of bloody course I'm p_ssed off when some comes and wildly but vaguely hand-wavingly - and arrogantly - "criticizes" my work, especially when he targets added value work (again: AFAIK no other benchmark/review offers series of runs plus compilation of the results at all).
@jsg Is it possibly to get more speedtests from local providers? It is not very relevant for US/EU, but "Western" provider in Asia are usually bad to real local providers.
For example, if you use the softlayer jp, you will get worse results usually than native provider like sakura internet.
I have all the good will in the world but keep in mind that my benchmarking is my private hobby, so I don't have lots of resources, people, etc, and in particular I have no VPS or dedi east of Moscow.
As NexusBytes has multiple locations in Asia I added a (reasonably fast and reliable, it seems) target in Hongkong; actually I added that target during the 2 long term tests.
But my benchmark software is free, so you and others users could run tests against a targets list of their own choice.
Also I could add a small server to my benchmark software that would allow users to run tests from their home but I see two problems, (a) probably due to a well known phaenomenon (few but loud "critics" while the majority stays silent/unheard) I'm not at all motivated to invest more work into my benchmark; it anyway does everything I was interested in, and (b) I don't know whether the providers would be OK with me publicly telling the IP of the provided test VPS and I certainly would not do that without their expressed consent.