Ok in LSI 9211 threat u asked to do a test with randoms reads..
here is some results from my array
Printable View
Ok in LSI 9211 threat u asked to do a test with randoms reads..
here is some results from my array
71K+ random 4K reads - 1486 MB/s random 64K - wow, that is pretty nice!
Where is the 20K+ pcmark vantage run!!!
well i dont think there is a need to run those numbers on a single ssd. there isnt a ssd in the world that will get even close to those numbers^^^^
new drivers released :)
+ 7-10 MB for me in random speeds with new drivers (windows 2008 server drivers)
I'm not sure if I did this correctly. 100% randon reads @ 4K for 30 seconds.
Single X25-M 160GB
http://www.freestylehair.mobi/io.jpg
I've monitored my qd quite carefully and no matter what I do it does not go above 7 and for the vast majority of the time it is hovering around 1 to 2.
No doubt I would get caned at higher qd's but speeds at higher qd's are just not relevant to me so I'm not bothered.
(Tiltevros - sorry don't mean to high jack your thread.)
Really nice numbers tilveros. I will copy what i said in the other thread about that spreadsheet:
At 4KB random you hit the IOPS roof at QD=24, at wich point you get 72928 IOPS @ 0,3001ms and 0,7904ms max. Those are really impressive numbers!
What also impresses me about this controller is from QD=1 to QD=10 you only gain 0,0233ms average latency.
It's also really nice you are able to exceed 1000MB/s @ < 1ms for 16-64KB random.
Now i would just like the numbers of a single x25-M on 9211 for comparing the scaling of multiple devices (the integrated RAID overhead). From what i can tell by just looking at the numbers, you have great scaling untill you hit the IOPS roof. For the larger packet sizes it seems the scaling reaches diminishing returns around QD = ([Devices]*[10(channels)])/([block size]/[4KB]), wich is where you start to see channel saturation.
Unfortunately we can't directly compare accesstime scaling by QD compared to a single x25-M with your 7-drive RAID, but using the related number for a 8-drive setup should not give large deviations. By simply calculating [RAID accesstime]/[singeldrive accesstime] for the same QD/#drives we should get the RAID overhead.
Did you use the 4k 100% read 0% random on the global access specifications to run you tests? How long did you run them for?
Can you let me know how to set the qd?
if possibel coudl you email be the iometer config file?
@ audienceofone
the configuration that i run is simple just use the profiles that iometer has like 512b 4k (make one with 8k) 16k 32k and just set the queue depth and change from sequential to random the ramptime that i used is 5 sec
and the test is set @ 30 sec. and just copy ur results to an excel. simple as this :D
@ gullars
the think that is blows my mind is that with intel G1 x25m the latency that u r getting is 0,08ms but i have 0,064ms.... can anyone explanes me why????
now i will run SEQUENTIAL test to see the results.. those drives are working for everyday enterprise useage.. and i havent touch them to erase from september.. (btw i dont know how to HDDerase also lool)
that is what I did: Access Specifications > Add 4k 100% read 0% random> Edit > change to 100 random. QD 1 to 4. No ramp up and a 30 second run per qd.Quote:
Originally Posted by Tiltevros
tiltervros is not getting the same results as you with the 9211 because he does not have cache or burst speeds that you are getting with the ich10r. it is best to run with a ramp up of 5 seconds as well. my 4k still outstrips that intel. :)
I miss one drive though :P
Sequential read speeds
Standard test. 2 mins with 5 second start up.
http://www.freestylehair.mobi/iops.jpg
wow very interesting results there audience of one. i wish we could compare access time too with that, as the single ssd seems to have higher access times with QD increases, at least on my setup.
i must admit im a little suprised at that chart, but also we need to take into consideration that tilt's array is very degraded, he told me the other day he hadnt secure/sanitary erased it since he has recieved the drives, and he hasnt done any trim functions, either. not sure if that is what the issue is with the scaling or not though.
we need access tiems comparisons !~!!!
@tilt!! did you use the sanitary erase i gave ya? lets see any differences!
(BTW tilt technet for 251 USD use promo code TNWIN7L)
New personal Record
OK here is the new results ..
Good results, I had expected more though.
It could be related to the new firmwares and mixing G1+G2, anyway the scores are great.
Attachment 100655
btw i did a new record in pcmark Vantage in HDD suite 50k+ last record was 44k
http://service.futuremark.com/compare?pcmv=271468
all the test that i did are with stock setting (S7025 cant be overclocked :'( )
Radar graph of the scores.
The radar diagram takes some getting used to but it's really informative.
Attachment 100656
Same here. It's still slower than a single x25 below qd4, but those high qd speeds are exceptional. Nothing comes even close on the wei scores for reads :up: (apart from the ioxtreme)Quote:
Originally Posted by Anvil
I'm a bit surprised at how well the Vertex array compares at low qds on the 9211.
u r forgeting something my friends... im on stock performance pcie 100 latency 64 and 1066Mhz of ram ;) those results with vertex are on high overclocked pc :D
now versus the 160GB ur drive is G2 right??? my arrays takes times from G1 with 400TB allready write drive ;D
hey, no one is knocking it....far from it :) :up:
Are those 512KB results or 512B? I'm guessing 512B since 5MB/sec is pretty low for 512KB tests.Quote:
Originally Posted by audienceofone
BTW I think you can attach the saved config for iometer so we can compare the same tests. I was thinking of even making one that would simulate a couple games :p
WoW, ME1 and ME2 (you can tell I'm excited right?)
^ dooh, B. I will change that later.Quote:
Originally Posted by Levish
Those configs are standard on Iometer. Look at the Access Specification tab and then select what you want to test from the global access specifications. You can edit a standard test to change parameters to random or write etc from there.
Anandtech use a custom config as detailed here. We should create something like this so we can all test the same thing :)
ok is there a posibility that if u r using different firmwares in ssd to get bad results?? espesially when u have 2 drives of 7?
ok ive done upgrade my drives from HA to HD something do u think that we will see any differents in random speeds??
@ anvil man i have bad news for u the excel file gone with a glass of water dont ask how lol. so if u can just use the table or wait till i make a new one :S
Tiltevros,
What you can do is to test them separately. (G1's in one array and the G2's in a second array)
I'm quite keen on seeing your scores using only G2's even if its just 2-3 drives.
I'll see what I can do without your spreadsheet.
new speeds for me almost 1,9GB/s without any cache ;)
Nice results Tiltevros
32K, 100%read, 0%random it looks like.
What is the size of the file and at what queue depth are you running the test?
its 64k :P
same as before but
almost 1,95GB/s 64k file sequential read @ 32 outstandings IO/s 4GB test file
@ Tiltevros
Which drives?
Post your results here too. You´re... :welcome:
@ all
Is there anyone with 3x Acard 9010 + this LSI?
@ fear
I dont speak german mate :/ and u dont speak english there :S can u help me through ??
The main-language is german, but is no problem to write a few sentences in english ;)
The only little problem is to register in our forum.
Or you write me a message with all your benches and with discription, and i will copy this.
ok im there i bookmarked the site and im looking forword to answer to ur questions :)
Google is your friend :D
http://translate.google.com/translat...ty%2Findex.php
RANDOM 64k file @ 128 outstandings IO/s
Tilt what are you using for a controller these days - the 9260 or the 9211 - excellent numbers in either case!
9211 im waiting the 9260 from day to day
I was wondering if anyone could help me, with my doubt:
It's the "Workstation" test in the IOmeter (8KB, 80% Read, 80% Random) and the 30GB "short-stroked" HDD (single or striped no matter) ...
Can anyone do a little test with the IOmeter measuring area limited to the first 30GB ("Maximum disk size" set to 30GB) and after that do a bench of a normal (non-stroked) empty HDD with a first partition of 30GB (IOmeter also set to 30GB "Maximum disk size").
Reason: I have a hypothesis to prove
TNX M8's :)
which is???????????????????????Quote:
Originally Posted by dh41400
Which is ... are there any significant benefits with "Short-stroking" HDDs when we are observing only first 30GB.
Many reviews and comparations of "Short-stroking" techniques are only based on measuring full capacity of HDD vs. short-stroked capacity ... which is IMHO wrong, it should be based on the same HDD area (ex. first 30GB).
Many benchmarks can not measure only one portion (ex. 30GB) of an non-stroked HDD, but only the hole area (full capacity) and that is why the performance difference is so huge.
As we all know, HDD doesn't perform equally on every part of his capacity.
IOmeter is a good tool (one of rare) for measuring performance of any part of HDD capacity that we desire (first 30GB in this case) without the need for short-stroking.
That's my hypothesis and I would like someone to test it, please (cus I don't have any empty HDD right now) :)
well you have come to the wrong place:ROTF:
j/k, however most of the stuff here lately has been with ssd, hopefully someone will help you though. If i recall correctly tilt doesnt even have a HDD, just tons and tons of intels:yepp:
Oh I couldn't wait so I dug up some older WD HDD and began to test it.
Hypothesis was correct ... no significant difference between "short-stroking" and partitioning first xy GB of the drive.
There was no difference even if the second part (partition) was filled with data, the first partition was running flawlessly - almost identical to the "stroked" drive (and I was a little surprised with this).
Next thing that I was planning to test is the "short-stroked" Striping vs. some cheap MFT'ed SSD ... the results should be interesting (regardless to the non-bootability of the MFT).
here is some updates working out with my latency i will post some iometer times later
wow .05 that is spectacular! looks nice :)
That is some great performance!
One question though. Aside from HEAVY server usage...why would a home/single user ever care to see queue lengths on IO meter greater than say 24 or 32?
because they are fun?
:)
dh41400
can't see u'r point with testing a short-stroked HDD vs a partitioned non short-stroked one through IOMeter,
there obviously shouldn't be any difference at all,
the HDD works the same as when it short-stroked to 30GB or u'r checking the last 30GB in it through IOMeter,
there is no difference at all at arm movement, this test is definitely superfluous.
lol, because it's interesting :).Quote:
Aside from HEAVY server usage...why would a home/single user ever care to see queue lengths on IO meter greater than say 24 or 32?
now for the main reason for this post,
didn't anyone notice the huge difference in 512B IO's from anvil 4*x-25v 183,000 on the ICH10R to this G2&G1 mutation?
why this 250$ dedicated HBA is getting choked at 75,000 IOps while the onboard ICH10R breath's smoothly till 245 KIOPs at 512B and even smashes it at 4K with ease at 110 KIOPs :cool:.
I've been busy lately so I haven't had time to follow up on the results and graphs.
I'll try again next weekend.
It would have been great fun trying 4 or 5 G2 160GB units using the ICH :) but the results are quite exceptional as they are.
never mind:down:
Actually it's not.Quote:
Originally Posted by onex
The main reason was to see if a second fully-filled partition would make any impact on the performance of the first one.
It doesn't.
Well it's easy to spot it now that the tests are done :rolleyes:
Actually disk load (# of Outstanding I/Os- IOMeter Loads) is quite different as opposed to the common knowledge.Quote:
lol, because it's interesting :).
This is thoroughly explained at the StorageReview and it can be easily monitored with perfmon.exe:
http://www.imagesforme.com/upload/fb...6e353931383038
As seen, the avarage disk load is far from single-digit numbers ... I'm mostly doing an average of 30-50 Outstanding IOPs (a.k.a. Queue depth).
BTW for the other subject - IOmeter results are VERY dependent on the number of workers and type of caching involved ...
You'll have to divide those 30-50 outstanding IOPs by the scale, in your case 100.Quote:
Originally Posted by dh41400
that's exactly what been said, maybe the word "last" should've been changed to "first", yet it shouldn't matter except from burst speeds.Quote:
Hypothesis was correct ... no significant difference between "short-stroking" and partitioning first xy GB of the drive.
There was no difference even if the second part (partition) was filled with data, the first partition was running flawlessly - almost identical to the "stroked" drive (and I was a little surprised with this).
you mean, while working only with the first one?Quote:
The main reason was to see if a second fully-filled partition would make any impact on the performance of the first one.
they're not supposed to be connected, the HDD reads data from it separately then from the second/third etc.
the head is moving only at the specified partition which is operative, not paying any attention to the other parts of the disk.
the only thing that could make any difference is reading the metadata which defines each partition which is supposedly placed at the MBR, or the volume boot record for a non-partitioned device.
so it seems at least.
this is right and also explained very nicely at ixbt labs article on IOMeter which everyone using it should read,Quote:
Actually disk load (# of Outstanding I/Os- IOMeter Loads) is quite different as opposed to the common knowledge.
lol, it point to storage-review article u brought as well.Quote:
Now a few words on the # of Outstanding I/Os parameter. If you set it to 1, then with the 100% Percent Random/Sequential Distribution we in fact measure a random access time. Value 4 corresponds to a load of an elementary applications like Windows Calculator. According to StorageReview, in average on real applications this parameter takes 30-50. The value more than 100 corresponds to high disc load (e.g. in case of defragmentation). According to it they suggest to take the following 5 values for this parameter.
the 9211 tiltevros used is an HBA, and doesn't use any caching at all, that's part of the difference between using a RC and an HBA, the other bench is taken from ICH10R 4*X25-V's by anvil,Quote:
BTW for the other subject - IOmeter results are VERY dependent on the number of workers and type of caching involved ...
and u should really have a close look at these results (brought by gullars) if u havn't, they're very detailed and magnificently put.
thanks for bringing that SW and article, it seems very very useful,
i'll go have a look at storage review input :up:http://www.xtremesystems.org/forums/...ons/icon14.gif.
edit -
LOL I'M SUCH A NOOB :ROTF:
how can that be anvil?Quote:
Originally Posted by Anvil
that means that some of the IO's are "fragmented" i.e 0.3IOs 0.2IOs etc..
that means up to 10 sec for one IO from that graph..
here's windows performance viewer, google earth (start&end) and some FF (middle),
(note the scale for the current IO's):
http://img691.imageshack.us/img691/9083/winpermon.gif
onex,
It's sampled every second and so it's not an exact number.
Start CDM and click on QD 4 or QD32 (or set qd in iometer) and watch the graph in perfmon.
thanks anvil,
2-128 exponential with IOMeter -> permon @ 1 scale:
http://img26.imageshack.us/img26/526...terperfmon.gif
proved :).
p.s dh41400,
can see u'r point in testing it, and why u were surprised with the results,
it strangely means actually that short-stroking fuzz is nothing and has no actual meaning at all...
this is so silly, how did they not think about that at toms hardware?
losing 80% of a 450 SAS drive when u can partition it with the same impact?
that's so idiotic it's actually hard to believe http://forums.anandtech.com/images/s...miliar/wtf.png.
you know that storage review stuff is so off that it isnt even funny then in regards to queue depth. i jsut dont understand how they could be so wrong about that for so long and nobody called them out on it :)
Their article is so ancient that perhaps during those times and considering the speeds of the storage devices at that time, what they had written was correct. Who knows. It definitely was not meant for SSDs.Quote:
Originally Posted by Computurd
I was measuring the performance of the WD Black HDD and considering all IOmeter benchmarks (mine and from other reviewers) it should get around 120-160 IOPs (depending on type and size of data).
Then put on some disk load and watch the perfmons results and it really starts to "stutter" above ~120 Queue lenghts (original scale), so the article on the StorageReview may be obsolete but the part concerning disk load measurement is quite accurate.
It is interesting that nobody noticed this before and that was taken for granted that a <20 Queue depth is heavy load ... and I'm not just talking about XS but worldwide forums as well :/
no offense dh41400, yet saying 120-160 IOPs on IOMeter without specifying the size of data is talking quite vague...
when u talk about perfmon as seen by the examples here (and anvil's sayings), you should specify whether it is default setting (which are different for certain measurements)
i.e - current queue length is 10 by default, others are 100.
if it is set to 100, as seen here, you should actually divide the results to fit a 1 scale.
it sounds odd, yet measurements shows IOMeter's QD of 120 to show 120 at perfmon @ scale 1, and running some software, shows up to 200 and down to 0 at scale 100.
this means, as seen up there ^^ avg. QD of 0.1-0.2 to 2.5 per second,
(as said here) it is measuring QD every 1 second so graphs aren't that accurate.
@1 hertz - not sure how different it is between an HDD to an SSD from that perspective, this should be checked,
after all, SSD are transfering the same data faster, yet it has more channels then an HDD...
p.s - CT, did a defrag test here (160G HDD), QD was minimal as well,
at SR they said it goes up to 120 :hm:...:)
Non taken :)
The disk performance is dependent on the type of data and the settings in IOmeter. I've been mostly using the default Workstation pattern with a default number of workers and the results were in limits mentioned above (dependant on the partition measured).
I was just looking at these graphs and found another more important item:
http://www.imagesforme.com/thumb/thumb_a047829c.png
Split IO/s are definitely the thing I've been referring to ... it's that limit on magnetic HDDs that just keeps them in "stutter mode" on heavy load.
There is a conection between the QD and these IOPs and can be clearly seen on the graph.
It is all explained pretty good on this site.
We are making progress (finally) and I'd like to do this again on a average SSD ... the results should be interesting and can maybe reveal a magic formula for measuring performance of a average home user config :)
as it been said, 120 by storage review, seems too much,
they talk about 2QD at u'r article @ normal activity.
intel SSD's (M&E) are supposed to take up to 32 tasks simultaneously.
this all data needs to be reprocessed and retested,
it could be that this HDD here suffers from bottlenecks.
it should be all checked with an SSD.
remark - note again the 100 scale (perfmon -> test pattern (avg. queue depth etc.) properties -> 3rd tab -> scale -> change to 1.
split I/O's are IO's that are split as they're being requested, due to defragmented medium or if (so said) a program asks for data that is too large to transfer at a single request i.e 1MB of
data while the system is transferring request sizes at 4KB (not sure about it, yet should be something like that).
u should see it best happening while defraging the drive.
I've seen what has been said but I'm also talking about results that were reproduced on my own setup (Workstation pattern) and the numbers are pretty realsitic 120+ IOPs (without any mistake, and almost in every configuration).
When we are talking about measuring real average home user configuration, the first thing is the type of files and the universal setup (at least for an system partition).
This is why all this results have to be "projected" into real-life performance and scaling which I've been doing A LOT in last year or so.
So the real goal is not to take a bunch of disks and just run the same IOmeter pattern, but also make sure that type of pattern represents real-life load and data transfer on the system partition (other partitions are mostly used for low-demand data such as big files and multimedia).
There is a whole bunch of tests and patters out there but very few represents the realistic situation and user based experience.
That's the real problem :)
that sounds strange,Quote:
I've seen what has been said but I'm also talking about results that were reproduced on my own setup (Workstation pattern) and the numbers are pretty realsitic 120+ IOPs (without any mistake, and almost in every configuration).
QD of 32 sound reasonable at high demand, yet still, perfmon shows other results.
ntfs goes 4KB to 64KB depends on the partition size, file matter as well indeed,Quote:
the first thing is the type of files and the universal setup
loading POP (dec 08) brings read QD up to 10
FF w 45 tabs loaded doesn't go over 2.5-3 at most.
note that prince is quite a light game, X3 has loaded with 5 outstanding IO's top.
aside from that, there doesn't seem to be any program advanced or professional enough to measure every aspect of the disk realtime except from perfmon, which is so ugly and deteriorated with these graphs and 16 colors,
that it is just ridiculous.
crysis or other performance app's might ask for more.
i'd say, in-serious developers or at the least, thoughtlessness of MS - no support for deeper system inspection,Quote:
That's the real problem :)
it'd be very disappointing to see that WIN 7 PRO doesn't support any decent tool either, maybe next google OS will,
generally this is BS, there should be something somewhere,
yet unless it'd appear suddenly or someone would create a serious one,
that indeed is quite a problem :mad:.