Printable View
IOmeter profiles for download
Random read 4KB (Testfile 1GB, default QD : 64)
Attachment 106702
Attachment 106703
Workstation (8KB - 80% read, 80% random)
Attachment 106704
Random read exp2 512B-256KB QD1-64 (aligned)
Attachment 106706
project random read linear QD scaling (GullLars)
Random read 4KB-32KB QD 1-32
Attachment 106707 (includes info in zip file)
...
I'll upload more profiles shortly....
** reserved for graphs **
Thank you for posting these. I will give them a try later.
Mr Anvil, appreciate all your hard work - this will be most usefull.
dont forget to teach people to use physical drive and not the file on disk emulation layer
Hi W1zzard, I think you are talking about using an unformatted drive for IOmeter versus letting IOmeter create the test file. What are the performance differences of doing it both ways? For myself, I am testing a current production drive so can't delete the partition, but I'm interested what the differences are.
Instead of creating a new thread I've decided to use this thread.
There is a new RC of iometer with the ability of selecting grades of random data.
You can download the RC at Link
Don't overwrite the old iometer as the new one still has a few annoying bugs, so unzip it to a new folder.
Bugs that I've observed are
If you save a new config using the RC you wont be able to load it again, can be fixed by changing the header in the config file but this is the only/main reason to keeping the old iometer.
The speedometer crashes the GUI on my computer.
Keep in mind that this is after all a RC and so there might be other bugs.
Attachment 110938
There are 3 options
1) Repeating bytes
Compressing a 1GB testfile using 7z (normal) results in a ~460KB file.
2) Pseudo random
Compressing a 1GB testfile using 7z (normal) results in a ~1.73MB file. (edit: from 1.73MB to 64MB, so far)
update:
Note, having tested the pseodu random setting it seems that the data generated is in fact so random that it just won't work for comparing iops.
In order for this setting to be usable for comparing/testing SF based drives it has to produce the same level of compression over and over again and it just doesn't.
3) Full random
Compressing a 1GB testfile using 7z (normal) results in a ~376MB file.
I've performed a few tests on a single SF drive, will post them a bit later today.
thanks! cant wait to see your SF results with incompressible data
Well, the data isn't incompressible.
It seems however that it takes a hit pretty quickly, with the data used the hit is approximately 20-25% on reads, I'll get back to writes later.
To recap.
repeat (blue line) is comparable to the old iometer, easily compressible data
pseudo (red line) is harder to compress but still compressible. update: compression varies and the factor is not predictable
full (green line) is much harder to compress.
4KB
Attachment 110952
16KB
Attachment 110953
Performance hit increased to 30-40% using 16KB.
64KB
Attachment 110956
Performance hit is now 40-50%
I have to say that this kind of data is highly unlikely unless the data is encrypted. Testing encrypted data is something completely different.
ty now i get it :)Quote:
repeat (blue line) is comparable to the old iometer, easily compressible data
pseudo (red line) is harder to compress but still easily compressible
full (green line) is much harder to compress.
very interesting data here. i wonder where the real life data pattern would fall, within the pseudo range? interesting how that effects the latency quite a bit, apparently overhead from compression algorithms on the SF controller?
write data should be very interesting data indeed. are you seeing results as markedly different with writes as with reads? i would guess there would be a slightly bigger gap there.
OFF-topic (kinda)
here is an interesting tidbit i ran across on another forum, interesting take on it:
so the writes, considering the data would be correct, would be where the differences in performance would be more noticeable with the SF, or any other controller for that matter. dunno i am curious as to you guys thoughts on that article as well....Quote:
Top 5 Most Frequent Drive Accesses by Type and Percentage:
-8K Write (56.35%)
-8K Read (7.60%)
-1K Write (6.10%)
-16 Write (5.79%)
-64K Read (2.49%)
Top 5 account for: 78.33% of total drive access over test period
Largest access size in top 50: 256K Read (0.44% of total)
Using Microsofts Diskmon, he simply monitored his typical computer usage in doing things such as using the internet, running applications, playing music etc. In short, he did his best to recreate the computer use of a typical user and then used the program to break down the percentage that specific disk access speeds were being utilized. In the end, it confirms something we always thought but just didn't really understand. Large sequential read and write access is utilized by the average user less than 1% of the time yet the most used method of access is smaller random write access as shown by the 8k write at over 50%.
http://thessdreview.com/forum/genera...cturers-bluff/
That red 64KB curve shows how bad Sandforce is at compressing data. Anvil found that "Compressing a 1GB testfile using 7z (normal) results in a ~1.73MB file", which is an incredible 578x compression factor. And yet Sandforce evidently could not compress it at all, since it took about a 50% performance hit compared to the blue curve.
My guess is that a lot of data on most people's SSD will be similarly hard for Sandforce to compress.
I think he is drawing a heck of a lot of conclusions from one person's dataset. I wonder whether the 8KB write data making up more than 50% may be representative of most people, or whether that user was doing something that highly inflated the number.Quote:
Originally Posted by Computurd
Actually, I am unclear on what those numbers actually represent. What exactly are they using to calculate those percentages? Is it percentage of time spent in each operation? (that would be the most useful in this context, I think) Is it percentage of total bytes for each type of operation? Is it just counting the number of I/O operations of each type and computing a percentage? If so, that would not give us a good idea of how important each is.
If you want your computer to feel faster, I think you want to see how much time is spent waiting for various types of I/O. If an 8KB write operation completes in 200 usec (microseconds), while an 80 MB write operation takes 1 sec to complete, even if you have 100 of the 8KB writes and only one of the 80MB writes, then you will spend 0.02 sec waiting for 8KB writes, and 1 sec waiting for a single 80MB write. So counting by write operations, you would have about 99% 8KB write, but speeding up the 80MB write (less than 1% of operations count) would be something you would notice, unlike the 8KB writes.
Now, I am not saying that my example above is typical. It probably is not typical. But it demonstrates that when profiling usage patterns, you need to be careful how you do it. I think time spent in each type of I/O operation is the best way to profile usage patterns in this context.
good point, i agree :)Quote:
I think time spent in each type of I/O operation is the best way to profile usage patterns in this context.
i think. i am wondering how they came to that as well. when he gets back from CES i will shoot him a pm and see. you make excellent points, thats what i was looking for, varied viewpoints on it :)Quote:
Is it just counting the number of I/O operations of each type and computing a percentage?
Ao1 should visit this thread, he's done a lot of monitoring day to day tasks using hIOmon.
From the top of my head, as a general rule of thumb, read/write is closer to 80/20. (just like the workstation pattern in iometer, 80%/20% 8KB read/write )
From one of the earlier documents compiled by Microsoft on pagefileLink
It's not typical but it's typical for one of the major tasks that runs on most pc's.
Should the pagefile be placed on SSDs?
Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.
In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that
Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.
In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.
Here is what I get using the Workstation pattern Aligned test file from post #1
Hi Ao1
As expected, the results using the Intel is not affected by compression.
I'll perform a workstation test tomorrow on the SF drive.
I've also performed a few write tests but I'll have to create the charts for them, performance hit is high but it's still faster than most SSDs
They have mixed the explanations for pseudo and repeatable afaiks.
I also wonder if the random data is created equally on all computers, random is after all random and if it's not created equally the compression factor would not be the same and one can't really compare results. (repeatable is ok, pseudo and full are the ones to look out for)
Do you have any figures for read vs writes, block sizes,... on day to day tasks from you hiomon testing?
Hi Anvil, I'll leave hIOmon running for a week to get a good average and will post some stats when finished. 80% read/ 20% writes sounds about right overall, but I suspect it will be different if you look at the device level only as a lot of small reads/ writes seem to get addressed without going to the device. I'll compare both anyway.
Physical drives are displayed with a blue disk icon. Blue disk are shown only if they contain nothing but free space (no defined partitions). Disk workers access physical drives by writing direct to the raw disk, so you are measuring the performance of the raw disk only.Quote:
Originally Posted by nbarsotti
Anvil,
I'm still puzzled by the what the aligned performance test is supposed to reflect. According to the Iometer manual:
12.9 Align I/Os On
The Align I/Os On control group specifies the alignment of each I/O on the disk, shown in the Alignment field (default Sector Boundaries). If the value of this field is n bytes, every I/O will begin at a multiple of n bytes from the beginning of the disk. You can select any value from 1 byte to 1023 MB + 1023 KB + 1023 bytes, but the specified value must be a multiple of the disk’s sector size. Entering the value 0 or selecting the Sector Boundaries radio button causes I/Os to be aligned on sector boundaries. (This value is ignored by network workers.)
Note: If the Alignment field is set to a value other than Sector Boundaries and the Size value is not a multiple of the Alignment value, sequential I/Os will not be truly sequential. For example, if the Size is 3KB and the Alignment is 2KB, each sequential 3KB I/O will be followed by a 1KB “hole” before the beginning of the following I/O.
I can't imagine that the above is something that would be likely to occur in real life? :confused:
Here is what I get using the Workstation pattern (non aligned test file) from post #1. Again its very similar between repeat, pseudo & random so I've only posted the repeat test.
Ao1
The example would and will take place using Windows XP and other old OSes.
Vista, W7, OSX are all natively designed for 4KB alignment, XP was not.
To make a long story short, iometer is by default aligned at 512B when what we really want is 4KB alignment.
4KB aligned would have been a better title for the charts but I'm thinking of 512B as not being aligned :)
A few links of interest that explains it well are
Anand on WDs Adcanced Format transition
Anands State of the Union article was the first to address this in a test
edit:
Although the X25 is designed for 4KB pages like all current SSDs, Intel optimized for 512B as well so for the Intels it doesn't make that much of a difference.
Other SSDs like the C300 is not optimized for 512B at all which is clearly seen in the State of the Union article at Anandtech.
Workstation pattern results using the V2 60GB on the ICH
Repeating bytes : 24405 iops / ~200MB/s
Pseudo random : 21387 iops / 175MB/s
Full random : 21467 iops / ~176MB/s
Pseudo and Full random are almost identical just like in the random read test.
The Vertex 2 is awesome at workstation pattern, I'll check how the C300 performs.
edit:
I don't have a single C300 available right now so I tested 2R0 C300 64GB on the ICH (using a 5GB testfile as opposed to 1GB on the Vertex 2 tests)
Repeating bytes : 25856 iops / 211MB/s
Attachment 110992
Vertex 2 60GB 4KB random write
Attachment 110991
I've included 2R0 C300 64GB. (my boot drive)
At QD1, performence is equal whether the data is easily compressible or not.
On the iodrive there is no difference whether the data is random or not (as expected). Used pseudorandom, this is workstation results:
Aligned: 61295 iops
Unaligned: 53706 iops
Aligned with QD=1: 20996 iops :D
Thats awesome :)
Maybe I should make a chart with more QDs?
I'll include your result in the Workstation chart, looks like I have to make a raid of a few Vertex 2s :)
Attachment 110994
I've been doing some more tests using the pseudo random data generator and it seems there is more to it.Quote:
Originally Posted by johnw
The compression factor varies, the generator is not suitable for testing/comparing SF based drives.
Using the pseudo random generator the compressed size of the file has so far produced 1.73MB up to 64MB 7z files. (still using normal compression)
Repeating bytes and Full random looks like the only options that makes sense for testing SF based drives.
Here's a small sample of the performance graphs I'm working on.
1 single Vertex 2 240GB
1 iodrive (One_Hertz)
1 LSI 9260-8i w/FastPath 4R0 Vertex 2/LE 100GB
I'll probably create a new thread with a different structure for easy comparison.
Attachment 113771
a few more samples are coming up shortly...
Attachment 113772
Attachment 113777
Need some ACARDs in there to compete with the iodrive! Get SteveRO to run it on his beastly ACARD array. Are you using incompressible data in your testing? Vertex results look like they were done with zeros.
Yes, the Vertex results (so far) have been using repeating bytes, pseudo random is coming up. (pseudo random is incompressible)
It doesn't make that much of a difference at qds 1-2, also keep in mind that the SF controller excells at mixed IO, random read is not that much to talk about vs e.g. the Intel X25 series.
I'll pm Steve for some action :)
The workstation graph includes a run with the V2 240GB using incompressible data.
Most real life data isn't incompressible, most databases are actually easily compressible.
Removed due to invalid results, test length to small on the Workstation tests, new one coming up...
The red line looks very odd... It is impossible to see more than double the result from QD1 to QD2. Test size too small? Some of your profiles are missing a zero in the test size by the way so only 200MB is being used instead of 2GB.
The size of the testfile has been 4x the size of the cache on the LSI 9260, so there is a small bit of cache in the results.
The red line in the lates graph is the WB cache on the LSI, it totally changes the way iops are handeled, WT is Write Through of course.
I'll check the profiles for the missing 0, the size of the testfile used is still correct (I've checked while doing the tests).
The WB results are impossible. The results are saying that the average response is less than 0.05ms on QD2. The drives are simply not capable of this. There is an error somewhere in that test. (all the workstation profiles you linked me use 200MB as test size.)
I've checked and the Workstation QD1-16 test was missing one 0 as you pointed out.
I'll redo the test on the 9260 and see what happens, still the size of the testfile was 2GB but that doesn't mean that the test was performed on the full size, I'll check.
I didn't get to test it on the 9260 as that pc already has the 9265 installed, the 9265 is w/o FP key but I was quickly able to verify that the workstation result were invalid, at least for the 9260.
Will redo the Workstation tests as as I get to them, not a big issue, meanwhile the Database pattern is fairly close to the Workstation pattern.
edit:
ioDrive Random read 4K-128K QD1-128
Attachment 113784
The ioDrive peaked 127K iops @ 4K QD128. (> 120K 4K iops @ QD32)
A few more detailed graphs using QD1-16 linear.
Attachment 113786
Attachment 113787
Basically, there is no competition for the ioDrive outside raid controllers.
edit:
The LSI 9265-8i is tested with a testfile of 4x the size of the cache, 4R0 Vertex 2 100/120GB drives. (used drives)
There is no FastPath key on the LSI.
Attachment 113788
I dont think Iodrive's low QD (1-4) performance can be touched by any SSD. ACARD is necessary. Iodrive also pulls far head in highly mixed small block read+write workloads(like fileserver profile).
Could you correct the Workstation profiles and rerun those two tests?
It makes zero difference on iodrive whether it is 100MB or 80GB due to it having zero write caching. I didn't bother rerunning it in the first place due to this.Quote:
Originally Posted by Anvil
Hi Anvil, any chance of including a 1MiB xfer in your test results :p:
Whew, that iodrive is fast.
Hi Ao1
You should try to make him an offer on that ioDrive :p:, maybe there will be a bootable fusion-io drive someday.
The seqential transfer doesn't fit the iometer profiles due to the QDs.
One would have to create a new separate profile for sequential IO, using the most common sizes like 128KB and 1MB.
I am NEVER giving up my iodrive. Hell, I am looking for a second one :D
This next week sometime :)Quote:
Originally Posted by One_Hertz
would be interesting to see a single acard drive, sans raid controller, btw mr steve-o. lets so those low qds 'unfiltered' on teh PCH! i bet theres some good stuff there :)
HOLY CRAP btw, number 36 in the world! LOL man you are awesome:worship::worship::bows::bows:
Really looking forward to some ACard action!
Look like he's been working hard on those points, we might see some more of him in the storage section when the new pcmv is realeased.
I wonder what impact the new version has on storage.
I'll be spending more time at hwbot when the X79 is released :)
Good morning all,
Iometer files located at -
https://docs.google.com/leaf?id=0B2A...thkey=CLer_rAK
One of the tests - I think - Random Read 4-128KB exp2 QD1-128_2011_aligned - locked up at test 6 for some reason, couldn't figure out why, all of the others seemed to run ok. :)
edit - all iometer runs with 2600k @ 45x
Some other tests just for comparison -
winsat with 2600k @ 45x
http://img508.imageshack.us/img508/3...satdisk45x.png
winsat with 2600k @ 50x
http://img819.imageshack.us/img819/6...satdisk50x.png
AS SSD - see screen shot for details of each -
http://img854.imageshack.us/img854/3...parep67pch.png
Today or tomorrow I will start 1880/16x acard.
Much thanks to Mr. Anvil for pulling all this together! :up::up:
Hi Steve :)
What can I say, your results doesn't disappoint.
I've prepared the Database QD1-16 for now but the other ones will follow.
Strange that the random read test stopped, I'll look into where it failed.
Also, I've included a single Vertex 3, at low QD it performs as most SSDs, it does leave 2R0 Intel 320series in the dust while using compressible data.
Looks like One_Hertz could need that second ioDrive :)
Attachment 113837
As we add more QD the graph changes slightly and the ioDrive is ahead of the ACards at QD128.
Attachment 113838
I am looking on ebay every day for a second iodrive, but I don't see anything :censored:
So at QD1 ACARDs are almost exactly as fast as iodrive? Looking forward to more graphs. For higher QDs I should be able to win if I find a second iodrive (or sell mine and get a 160gb iodrive duo).
truly amazing results with those acards and the PCH! wow!
These are great results.
Wonder whats going to be able to compete with ACards or the ioDrive.
Attachment 113839
Attachment 113840
WebServer makes it a bit more interesting, looks like the ioDrive is the winner as we are doing reads.
Attachment 113841
Attachment 113842
I was planning on 3d benching a 580 under dice this weekend but I killed that card :eek: so I have been drowning my tears in iometer instead. :rolleyes:
All tests below where with Areca 1880/4GB 16x Acard 9010 R0 with read ahead disabled, 2600k @ 45x multi :)
Read ahead disabled seems best for acards.
Based on AS SSD, any read ahead seems to just get in the way. :)
4k strip, 64K cluster (same as for the PCH).
Iometer test file size - complete drive filled, 28.4GB (0 GB free).
Edit - Turns out that these iometer runs where all at 2GB used, even though the file created was 28.4Gb - as such these runs are using the Areca 4GB DDR2 cache to unfair advantage :(
Iometer files located at -
https://docs.google.com/leaf?id=0B2A...uthkey=CIyYugY
The same test - Random Read 4-128KB exp2 QD1-128_2011_aligned - would not run beyond test 5 all the others ran to completion.
Data seemed more erratic but some of the numbers looked huge. :)
AS SSD and wei winsat disk for this config -
http://img707.imageshack.us/img707/7...eadaheaddi.png
You actually used 2GB, at least in the 4KB RR test. The file shows...Quote:
Originally Posted by SteveRo
dammit! - check some of the othere for me.Quote:
Originally Posted by One_Hertz
I created the full disk file but the runs didn't use it?
Does - Maximum Size 4000000 mean 2GB?
So 6GB would be 3x - 12000000?
12GB - 24000000?
OK so new iometer files - just two as a sample - Areca 1880/4GB 16xAcard 9010 with the runs using 48000000 sectors or 24GB - performance w/o the cache does not appear so good -
https://docs.google.com/leaf?id=0B2A...thkey=COXR1d4O
what was the 4krr qd1 with the larger testfile? i see a database test there....but was there a straight 4krr qd1 on the 1880?
@CT
There was an issue running the random read tests on both the PCH and the Areca, don't know why, there really shouldn't be any issues with that config.
QD1 (database) using the large testfile was close to 100MB/s, not bad at all.
The Areca results are not so impressive outside cache, compared to the previous runs using the PCH that is :)
The latest runs are fine, you don't need to run 100% span, 16GB is sufficient and that might improve the results a few %.
Attachment 113845
Attachment 113846
I've performed a few tests on the 9265 and the results are coming up within 30min or so.
Anything with cache is going to be slower with ACARDS. ACARDS are so fast that adding another layer data must travel to just slows everything down. Iodrive manual mentions never to use caching with it since it would just be slower.
Meaning that when X79 enters, Steve's ACards will be really extreme :)
The 9265 is pretty extreme, not so much at QD1 though.
w/o FastPath, 8 Intels resulted in
235201 4K iops
161972 8K iops
and almost 100K iops at 16K
Attachment 113847 Attachment 113848
At higher qdepth the 9260 with or w/o fastpath looks to be a huge performer.
What is the highest typical workstation qdepth, seems like I saw a number once - 5 or 6?
Has anyone run himon while executing pcmv or pcm05?
Curious what the qdepth looks like for those.
Yes, w/o the FP key 9265 needs high QDs to perform but thats what its made for, a large number of users.
I'm waiting for the FP key and that should make a difference, Computurd should have run some of these tests if he's still got the SSDs and the controller :)
If you look in the hIOmon thread I'm pretty sure I did monitor a PCMV HDD test, all info should be in the screen-shot.
I'll see if I can find it later today, from what I recall it had a pretty high QD. (could be a short burst)
Comparing the ioDrive vs the 9265 with 4R0 Vertex 2 and 8R0 Intels
Attachment 113851
Steve
About the PCMV monitoring, look at page 7 in the hIOmon thread, starting at post# 173 and going on into the next page
Hi Steve,
In post #174 Anvil came out with an overall average read I/O operation QD of 2.033 and a maximum of 73. For writes it was QD 1 for avg and max. This was recorded at the device level.
In post # 178 Anvil came out with the following for the HDD suite test. (Again at the device level). read avg 2.572. Max 77. Write avg 1.169 and max = 13.
EDIT:
I monitored xfer sizes with PCMark at the device level. You can see the output file here: (It is too large to view online, but it can be downloaded).
http://cid-541c442f789bf84e.office.l...e.aspx/.Public
^^ Thanks guys, I will read up!
i still have the drives and the keys. i will run these shortly :)
Thats great CT!
You'll find the profiles at this link
running all of them now anvil. pm your email addy and i will jsut email the results, easier that way :)
http://cgi.ebay.ca/Fusion-io-ioDrive...item3a656ec3f7
damn this is a good price. $2650 for a 320gb iodrive. Those are 10k new. It is used however and does not say if its MLC or SLC. Looks SLC. Looks stolen. Perhaps I will drive down to check it out since its 5h away from me... Too bad the capacity would be lost on me since I would just use 80GB of it to raid it with my iodrive haha.
who cares if its stolen. buy it for the betterment of mankind :)
5 hour drive, might be worth the look :)
Is there some way to know how much "life" there is left on the NAND?
Isn't the 320GB faster than the 80GB?
The device firmware records how much data was read/written and the driver displays that info. These things basically last forever though due to grade 3 enterprise SLC NAND and their wear leveling... Something like 40 Petabytes of writes for the 80GB version, so 160PB for the 320GB unit. Reliability is one of the major selling points.
I do have $3k to blow on useless stuff right now, but an IOdrive that large.... I don't know.
Yes, the 320GB is faster at writing than the 80GB by about 200MB/s.
If you flash the firmware the read/writes are set back to zero.Quote:
Originally Posted by One_Hertz
I bet One Hurtz is in his car right now. :rofl:
I'm also betting that Intel used IOmeter for this bench, so I guess this belongs here. Interesting anyhow.
nice graphic. i am of the thinking that when NCQ is in full effect the drives accesses are 100 percent random. this stacking of commands and paralleling of them would result in random I/o. however, random I/O over several channels, as we see, can be blistering fast in regards to small file I/O.
WOW he dropped the price down to 2k. I'll get in touch with him on Monday and buy it as long as it is SLC :). SteveRO here I come.Quote:
Originally Posted by One_Hertz
Where are the results? :slapass::slapass:Quote:
Originally Posted by Computurd
Working on it :)
oh yes and guys ive got something that should blow your socks off coming soon...oh my my :) i am very privileged as of late, and i thank the computer gods believe me :):worship::worship::worship::worship:
Anvil The iometer patrens that you posted are they suited for testing raidcontroller cache memory?
I put a new 2gig stick in my 1680 but i didn't match the spec's exactly but it works only i don't know how well.
Would a 6hour or longer test run of iometer revael any problem (data corruption ect)?
@xeon_1
I don't think so, these test do not cover integrity testing of data and so it would not report any other error than media errors as far as I know.
The controller might report errors as some of the tests will stress the system quite a bit.
Is this for HDD testing?
I've compiled a few of the graphs and at low QD the results aren't particularly impressive when comparing to the ACards or the ioDrive :)
For some reason my 8R0 Intels (LSI 9265 w/o FP) perform better than the 8R0 C300 w/FP at high QD and they really shouldnt.
My X25-Ms delivers ~50K read iops having upgraded to 02M3 but writes didn't change much from 02HD, that would mean that the C300 are bad performers at mixed IO vs the Intels, it might be so and I guess we won't know for sure until someone gets FP or if CT can redo one of the tests, in case of some config error.
(on one of the tests (WebServer) the results are almost identical between WT and WB and I expect this is merely a user fault :))
Attachment 114154
Attachment 114155
Attachment 114156
Attachment 114157
The array consites of HDD's yes since it is my primairy storage/VM server.Quote:
Originally Posted by Anvil
But before i put it in opperation i need to test if the controller and the ram are fully compatible.
The ram itself is error free tested this in a pc
Gueus i can write a batch file to copy a couple of iso's back and forth and then do a checksum on them for errors.
@xeon_1
Yeah, not much else you can do except for doing some intensive testing yourselves.
I'm sure there are products that can do these sorts of tests for you, I'm just not familiar with with any of them.
If anyone is interested, I got in touch with the guy and his IOdrives are 100% healthy, however they are MLC. MLC is near 2x slower so I do not want it. It is still an amazing price though and it will smoke anything minus the ACARD and SLC Iodrives.Quote:
Originally Posted by One_Hertz
I have zero use for such a large drive. What I really want is another ioXtreme. I've been searching eBay for the last 3-4 months for one. I've only ever seen one for sale and he wanted $1200 for it. :down:Quote:
Originally Posted by One_Hertz
Guys, what is the trick to get iometer to save .icf configuration files.
No matter what i do, when i reopen the .icf all my config data is gone?
The rc from 2010 had issues with profiles, not sure if there is a new one.
So unless it is fixed just use one of the older ones for saving configs.
edit:
You could try downloading the latest build (~2 months old) from this link
(I have not tried it yet, it might have fixed the issue)
thanks for the link anvil! nice i will be using this immediately :)
@steve- nice to see you around :)