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
You said if you don't want people complain about DD results, don't advertise DD results. I'm saying it's not as simple as that. As explained on my previous post here, 'advertising' or having someone mention your DD results gets you sales in this industry. So you have to advertise if your setup producing good DD results which people love. Providing good DD results shouldn't be the target in an ideal world, it should be a sign of good performance. But unfortunately it is not. (It may be a sign of bad performance, I agree with that now)
However it's quick and easy to perform, and will instantly uncover if the VPS/node has an I/O problem. No one says that people should lose sleep over 300 MB/sec vs 400 MB/sec, what's important is to check if you get an especially low result there.
Solution is in educating people.
Also things like Top Provider polls are important, that way people can choose based on reputation (which builds from things like stability and quality of support), rather than raw price and specs numbers.
what would be a better way to measure IO instead of the DD command?
why aren't we using it instead?
Maybe instead of LEB being purely about pricing ($7 a month or $48 a year), it should be based on specifications. Define RAM, hard drive, and other limits. The problem is that LEB implements an artificial pricing wall. If you can offer it for $7 a month, it's okay, no matter what. If you removed this pricing wall and instead put in a resource wall where all providers are advertising more similar products, it'd be great. Now, a provider can advertise 256MB RAM for $7 a month vs someone advertising 4GB of RAM for $7 a month. Those products are not even remotely comparable. However, if we had two people advertising 256MB RAM for $2/month and $5/month respectively, we're at least at a level playing field. Provider #2 has to now justify their product in terms of quality, not quantity if they want people to pay 250% more for the VPS.
tl;dr - LEB should be more about the B and less about the $.
Of course you know
As a tech person you will know how big nonsense this race for big numbers is, as a sale person you will know how important this is, but pragmatically live happily ever after.
A little less happy will be clients with lower dd results (not knowing what exactly this brings them), but that's not really your problem as those wont be clients at your gear, but problem of a competition less capable to walk with trends, and this is it.
Pretty simple actually as long you can walk with trends
Is there still hope for that here? I wish to believe that too, but market overtook it, I am afraid.
In an ideal world, you shouldn't be measuring at all. Because you know what? Benchmarking on a virtualized platform is never accurate. VMs and containers don't have access to the hardware directly, they are all emulated.
If your VPS is slow, you should explain how it's slow to your provider and he should run his benchmarks on directly on the node and solve the issue.
However, as @rm_ said, it won't be easy to "prove" something is wrong on your VPS without some info on some cases to your provider. So, yeah...
BTW, does anyone know where the rationale for bs=64k count=16k came from?
Usually I do not benchmark a VPS i just ordered unless it has issues completing tasks that i'm trying to get done. What software would you recommend to run benchmarks with in such case?
Are services like serverbear reliable to proof that my vps is performing bad? what kind of benchmark would you like customers to return to proof it?
What do you think?
========================================================================
BYTE UNIX Benchmarks (Version 5.1.2)
System: server2.imag.hk: GNU/Linux
OS: GNU/Linux -- 3.11.0-19-generic -- #33-Ubuntu SMP Tue Mar 11 18:48:32 UTC 2014
Machine: i686 (i686)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: QEMU Virtual CPU version 1.5.0 (4200.0 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization
CPU 1: QEMU Virtual CPU version 1.5.0 (4200.0 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization
CPU 2: QEMU Virtual CPU version 1.5.0 (4200.0 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization
23:21:10 up 1:26, 2 users, load average: 1.73, 1.48, 1.77; runlevel 2
Benchmark Run: Wed Apr 02 2014 23:21:10 - 23:49:06
3 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 9500314.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2232.5 MWIPS (9.8 s, 7 samples)
Execl Throughput 212.8 lps (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 130324.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 36300.7 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 425069.8 KBps (30.0 s, 2 samples)
Pipe Throughput 253598.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 61318.1 lps (10.0 s, 7 samples)
Process Creation 367.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1223.3 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 445.7 lpm (60.0 s, 2 samples)
System Call Overhead 669555.9 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 9500314.5 814.1
Double-Precision Whetstone 55.0 2232.5 405.9
Execl Throughput 43.0 212.8 49.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 130324.2 329.1
File Copy 256 bufsize 500 maxblocks 1655.0 36300.7 219.3
File Copy 4096 bufsize 8000 maxblocks 5800.0 425069.8 732.9
Pipe Throughput 12440.0 253598.5 203.9
Pipe-based Context Switching 4000.0 61318.1 153.3
Process Creation 126.0 367.2 29.1
Shell Scripts (1 concurrent) 42.4 1223.3 288.5
Shell Scripts (8 concurrent) 6.0 445.7 742.8
System Call Overhead 15000.0 669555.9 446.4
========
System Benchmarks Index Score 254.9
Benchmark Run: Wed Apr 02 2014 23:49:06 - 00:17:19
3 CPUs in system; running 3 parallel copies of tests
Dhrystone 2 using register variables 27119185.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 6225.0 MWIPS (10.1 s, 7 samples)
Execl Throughput 1424.9 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 155024.8 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 41673.8 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 436966.4 KBps (30.0 s, 2 samples)
Pipe Throughput 582318.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 145035.8 lps (10.0 s, 7 samples)
Process Creation 3438.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2756.4 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 675.7 lpm (60.2 s, 2 samples)
System Call Overhead 1437140.2 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 27119185.7 2323.8
Double-Precision Whetstone 55.0 6225.0 1131.8
Execl Throughput 43.0 1424.9 331.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 155024.8 391.5
File Copy 256 bufsize 500 maxblocks 1655.0 41673.8 251.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 436966.4 753.4
Pipe Throughput 12440.0 582318.5 468.1
Pipe-based Context Switching 4000.0 145035.8 362.6
Process Creation 126.0 3438.8 272.9
Shell Scripts (1 concurrent) 42.4 2756.4 650.1
Shell Scripts (8 concurrent) 6.0 675.7 1126.2
System Call Overhead 15000.0 1437140.2 958.1
========
System Benchmarks Index Score 598.3
I'd say SSH feeling laggy, iowait (wa % on top command) being high, website loading slow, software installation being slow, tarring/untarring (without gzip) being slow, etc.
If you want a real IO benchmark, use bonnie++
Or use vdbench, designed specifically to destroy your storage cluster
Why was your load average high before running this benchmark?
No, it really is. If you're going to advertise services this way, then suck up the complaints, don't whinge and educate your customers as has been suggested already.
I think that's after the benchmark
Actually, we didnt advertise dd, but people kept asking and freevps.sh tests include it.
I find it an axiom of LEB/LET that if you advertise by whatever is popular at that moment, not only that you will not get reliable customers (they will jump ship as soon as there is another benchmark slightly higher from people cooking up their servers for that), but also people which are likely to get their VPSes hacked because of the popularity of panels such as kloxo and zpanel or because they have to run an open proxy because they do not know how to setup their authentication on the phone for example.
When you come from the business sector where people usually hire IT specialists, you do not see these things at first, but you learn along the way.
I say leave this kind of customers to the new hosts, they will learn or fail quickly and organize to offer stable and dependable services at affordable prices, this will get you the right customers.
The rest is dogma and theology.
P.S. the "dd test" was creating issues way before serverbear came online.
For most use cases, running FIO with 4k random read/write is going to give you the best indication of how the disk IO subsystem will perform.