My ioping is better than your DD

[Lee]

So many posts, over such a long period of time and nobody can agree.

Do you think it's possible to say, look run x to tell you whether you vps disk IO "may be an issue" and then run y to see if your network transit is good?  Whilst at the same time saying if x or y is < z you may want to query it?

Maybe a big ask I know but still, views?

 

[Damian]

Indeed, i'd much rather have durable <0.5ms ioping times than 700+mb dd values. I'm usually doing random i/o, not block writes of gigabyte-sized files.

 

[jarland]

Personally I don't care. The provider should be putting clients on a server that can handle the load and should be actively monitoring for abuse. If the client wants to see dd, ioping, or ask how often I do my laundry, I'll tell them whichever detail lands the sale. It's all truth.

 

[Lee]

The provider should be putting clients on a server that can handle the load and should be actively monitoring for abuse.

Lol, funny guy.

 

[Slownode]

I always develop my software to work as smoothly as possible with ~20ms IO lag so offsite storage is invisible. Throughput and CONSISTENCY(CONSISTENCY!) are my major concerns.

 

[AnthonySmith]

Sadly with ioping 99% of the time you are just hitting the disk cache anyway when getting good results which is no reflection on random seek time.

Frankly I think both dd and ioping tests are a waste of time as a benchmark on a VPS, they are fine as an indication only though, I have had tickets opened in the past saying "

my dd speed is a little low and ioping is spiking everything is running great and my sites are as fast as ever but I would really like this to be resolved" at which point I do an epic face palm.

A VPS is a shared resource environment the dd or ioping test you have done is valid for all of 3 seconds and the results are probably skewed anyway, ioping will always give better results on openvz due to the way it fails to separate storage resources so you are just hitting the drives cache, and the dd test is probably running in the raid cache 50% of the time and regardless it is a sequential write test, no one is using a VPS for sequential writes.

My personal tests for a VPS to make sure it is fit for purpose:

A) Define the purpose.

B) Does it feel snappy enough during setup

C) Define a repeatable test i.e. siege test/ load runner a website, 

There is a good reason you can test the same package from the same company 100 times and get 100 different results, and that is because you are not paying for dedicated resources so your experience will have a degree of variation, if you are deciding that a VPS is of no use to you to host a blog because the dd test gives you only 40 MB/s then you need to stop smoking internet crack and do some actual thinking.

An example I have used in the past:

Same 3 tests on 2 hosts, you plan to run a busy blog/forum which one do you pick:

Host A

UnixBench: 2457

DD: 125 MB/s

ioping: avg of 10 pings = 0.04ms

Host B

UnixBench: 1482

DD: 84 MB/s

ioping: avg of 10 pings = 0.13ms

Obviously based on that data you go with host A despite the fact that none of those results actually impact your intended use at all.

Here is the same data again but with 3 extra bits of data that no one EVER puts on benchmarks or reviews:

Host A

UnixBench: 2457

DD: 125 MB/s

ioping: avg of 10 pings = 0.04ms

AVG Upload speed from 10 locations: 14.7 MB/s on HE only bandwidth

AVG Latency to primary target audience: 57ms

Siege test: 840 page loads p/second

Host B

UnixBench: 1482

DD: 84 MB/s

ioping: avg of 10 pings = 0.13ms

AVG Upload speed from 10 locations: 68.7 MB/s on level3+blend bandwidth

AVG Latency to primary target audience: 31ms

Siege test: 2134 page loads p/second

So with the 3 pieces of relevant information to your intended use you would now be insane to still pick Host A over Host B as host B will clearly serve your purpose significantly better, if however you just want to smash your e-penor in to threads with dd results then go ahead and pick Host A you have no hope of doing anything well in life apart from looking good (on the surface at least)

So yeah, ioping is great to monitor disk load on an active dedicated server as it will give you a constant output of how your doing under load, for a shared environment especially those that use LVM and virtual block devices it is a wast of time on every level. 

dd gives you an indication how fast a drive/disk array can write a bunch of 1's right next to each other and in order which reproduces nothing you will ever do on a VPS and if you do on a regular basis you should be getting a dedi.

That is my 0.47c on the subject.

 

[jcaleb]

Sadly with ioping 99% of the time you are just hitting the disk cache anyway when getting good results which is no reflection on random seek time.

I will try create review for your suggestions boss. Will you help me define more data that is helpful?

 

[Slownode]

Someone needs to make a benchmark called "clusterbomb" all it does it writes files to random directories as fast as possible, and keep track of where it's dumping crap to then read it all, then delete the crap.

I could make that but then I'd go to that part of hell where bad sectors come from.

 

[Damian]

Sadly with ioping 99% of the time you are just hitting the disk cache anyway when getting good results which is no reflection on random seek time.

 

[RyanD]

All of these ioping and ddtest and iozone and sysbench and whatever else tests make it a point to bypass disk cache and controller cache and whatever else has been put in place.

 

There in lies the problem of all these "bechmarks" you are only stressing raw i/o output from the most unlikely of realworld scenarios. That is unless your server is specifically used only to run dd's and iopings. 

 

[kaniini]

Personally I don't care. The provider should be putting clients on a server that can handle the load and should be actively monitoring for abuse. If the client wants to see dd, ioping, or ask how often I do my laundry, I'll tell them whichever detail lands the sale. It's all truth.

If the server is properly configured (i.e. using bfq-iosched), then there is no such thing as I/O abuse anymore.

 

[AnthonySmith]

Go find the article on the £300 vs the £3000 gaming rig competition.

They built a MONSTER £3000 gaming system and the best one they could for £300

Got some genuine pro gamers in, monitors and input devices were the same, they infact did not actually tell them the point of the competition and they were not given any spec info, when asked afterwards which one they liked the best performance wise on a number of variables (again still not knowing the difference at this stage) almost 50% picked the £300 rig and no one noticed any problem with it at all the only real world difference that was spotted was the load time on the games i.e. SSD raid vs single Hitachi death star drive but none of them thought it was a "problem" yet in benchmark land the £3000 rig pulled about 8 x the score of the £300 rig.

Like I said, use real word performance metrics that reflect your intended reason for use or you are just wasting your time with your dd and ioshit, you can get a VPS that will do 1.2GB/s on a DD test and it may be connected to a badly over provisioned HE only 100mbit pipe so your game server performance will LAG and your websites will crawl.

 

[Lee]

The sensible approach is always to base your view on whether it is fit for purpose, the purpose being key as that will/should determine what you require before the price does.

That said I can understand why DD and Ioping are held in such high regard by the customer.  Big numbers from such a quick and easy test are indicators of good quality and low number represent oversold ovz nodes.  Whilst we know that is not always the case it is not really the customer that is driving that in my view.

There are so many providers claiming to be that something they are not and offering services they do not.  I even see providers on IRC and other places saying things like "yeah we say we offer raid10 but it's really only raid1, but it runs fine".

Of course everyone likes to play on the "you get what you pay for" so just because I choose to pay $5 where others charge $30 means I should automatically expect they will not be able to provide the service they offer and advertise?  I don't think so.

The ram race that many attribute to "client demand" is also a myth, it's been driven by the significant volume of budget providers constantly jostling for a share of an already overcrowded market who then struggle to maintain a viable/reliable service.

My point again is that the clients desire to see big numbers on DD and ioping are firstly through the mis-guided following of those they say it's the best way to test a VPS, however it is also because they want to have a level of confidence about performance before putting the effort into using it for whatever they purchased it for.  In this market who can blame them.

You will never convince people now that DD is not a good test, it's too deep seated in the mindset of many.  Maybe it's not about testing to find out how amazingly fast your vps is, perhaps it's more simply about how to test whether you bought a complete dog?

I don't claim to have the answers, the thread was more about the frustration of constantly seeing thread after thread with posts saying "Oh my, cancel that the DD says it's only 345mb/s which is ridiculously slow nowadays".

 

[notFound]

Sadly with ioping 99% of the time you are just hitting the disk cache anyway when getting good results which is no reflection on random seek time.

That's what -d and -s are for. ;-)

 

[vanarp]

That's what -d and -s are for. ;-)

 

Do you suggest something like below is a better way to check direct i/o performance?

ioping -D -c 10 -s 0.5m .

 

[jarland]

Basically I would have to agree that the test serves a purpose. Perhaps it is held too highly and it's results considered too relevant, but that reality does nothing to decrease it's relevance. If I run a dd test and get 5mb/s I'm never returning because this provider is clearly allowing insane abuse or adding on storage with Zip drives over a parallel port.


Bottom line: Good results aren't necessarily a good thing. Bad results are almost certainly a bad thing. The test is often granted too much weight, but the test is far from irrelevant.

 

[AnthonySmith]

Basically I would have to agree that the test serves a purpose. Perhaps it is held too highly and it's results considered too relevant, but that reality does nothing to decrease it's relevance. If I run a dd test and get 5mb/s I'm never returning because this provider is clearly allowing insane abuse or adding on storage with Zip drives over a parallel port.


Bottom line: Good results aren't necessarily a good thing. Bad results are almost certainly a bad thing. The test is often granted too much weight, but the test is far from irrelevant.

What if someone was running something that required insane disk I/O for 30 minutes? what if someone was running something insane for 15 minutes on one of your nodes at the same time a new customer ran a dd, and they tried it 5 times in 15 minutes to be sure, should they leave and never come back?

I dunno, my approach would be, test the relevant stuff, do a dd and ioping if you must, if not great open a ticket, if still not great then leave.

 

[jarland]

What if someone was running something that required insane disk I/O for 30 minutes? what if someone was running something insane for 15 minutes on one of your nodes at the same time a new customer ran a dd, and they tried it 5 times in 15 minutes to be sure, should they leave and never come back?

I dunno, my approach would be, test the relevant stuff, do a dd and ioping if you must, if not great open a ticket, if still not great then leave.

I can't imagine what one person would run, that I wouldn't immediately heavily ionice (because we'd have to be talking serious, lagging out the entire node territory), that would cause such a low result from a dd test.

What I think we're all forgetting is a time not too long ago when an extremely low dd test value was a very good indicator of something that was happening left and right. Providers now may be getting better about it, but it wasn't that long ago that if you said "the result was 5mb/s" I would be forced to reply with "Why did you buy a VPS from volumedrive?" It meant something then, still does, albeit a little less because the shaming that came from it forced provider's hands at learning how to at least manage a basic disk array (or learning how to fake it better).

 

[peterw]

Bottom line: Good results aren't necessarily a good thing. Bad results are almost certainly a bad thing.

I do not care about the dd results. Why should I care if the vps is snappy and I do not have much io wait?