you partitioned a RAID0 drive?Thats a no-nobesides, if its motherboard RAID, FSX is killing you anywayand if it was not a RAID array, splitting a drive into 3 partitions like that and putting FSX at the end?If I were you, I would start clean, get rid of RAID and just use the drives by themselves

i can see what your saying about partions and yes I did start fresh with windows seeing one drive now.It is still raid0 but I think that will give me better performance anyway.it is motherboard raid as opposed to a controller card. how is fsx killing me? i dont understand. all was well until I used ultimate defragger.

well here is the tests with my raid0 config with a 64k cluster size or block size. this is with no partitions now. is 202.7mb/s burst pretty good?

I hate to be the bearer of bad news but here goes...1. HD Tach is well known for erratic results in the burst and the sequential read. Something as simple as a driver change can change the readout by quite a bit. On top of that FSX is a random access file system and the sequential read speed of a benchamark means nothing. Sequential read performance would be for a massive video file that is a gig in size. Also, for a sequential read benchmark check, you want a STRIPE of 2-8K MAX, the same as if you were using the array as a A/V production studio drive.2. A 64K STRIPE is far too low for FSX. Even if you are running a confirmed 250MB/s (sequential, not burst) the latency on the heads of the drives in the array seeking file chunks @ 64K increases the load on the system by a --massive-- amount and therefore @ 64K the RAID array is SLOWER than a single RAPTOR drive in FSX. 256K is the minimum for optimal performance. FS9 can use a 64K STRIPE, FSX will clobber a RAID array @ 64K which leads to the next part...3. One area HD Tach is accurate and its the ONLY area I look at when I use the software and that is the CPU Utilization. You can kiss that 15% of the CPU goodbye which is magnified by the latency produced by #2.2+3 = POOR FSX PERFORMANCE Motherboard RAID takes between 10 to 20% of the CPU away from the system and FSX. The processor and the overclock it may be giving you is being drained by motherboard software RAID. So in your case if that 5000+ is running 2.6GHz, you just turned it into a 2.2GHz (or less) processor, and, the expensive RAPTOR drive is working 2x harder to deliver the file chunks @ 64K, therefore not only have you removed the CPU from FSX you have reduced the ability of the RAPTOR by 25-50% in access time depending on the size of the file being called.You are better off on a single RAPTOR or other large HDD in FSX than on any motherboard RAID solutionThe 2xRAPTOR RAID array I use is from a hardware PCIe x4 RAID card which has 256MB DDR2 533MHz memory on the card for cache and requires a 1 to 2% MAX CPU when in use. It also allows a STRIPE of 256K which is in line with the average files size in FSX.There is a reason a real RAID card costs 3-400 dollars and more and a reason real SCSI raid solution costs thousands. Its the same reason Intel gets so much for multiplier access and the memory stick companies get so much for low latency, high speed memory. You do get what you pay for. Motherboard RAID is joke and always has been however for FS9 the file size was so small and the number of files accessed did not hinder motherboard RAID and hardware anywhere near as much as FSX and those solutions worked with a trade-off of fast file access for CPU. Since FS9 is not anywhere near as CPU bound as FSX, the RAID solution provided a gain. In FSX its grinding your FSX results into the ground.Its good you got rid of the partitions, thats a definite plus... but I would also consider getting rid of the motherboard software RAID array all together.As for defrags.. If you did not like UD, try O&O. I highly recommend it. v8.6 works fine in both XP and VISTA. O&O has a special going on which was made for the folks at AVSIM, buy v8.x and get v10 for free.http://forums.avsim.net/dcboard.php?az=sho...d=441401&page=2

Follow UpHere is how much BS HDTach is feeding you....This is my array, a professional setuphttp://forums.avsim.net/user_files/187301.jpg114MB/s? I dont think sothe 2% CPU use is real.. but thats about itNow, here is truth...http://forums.avsim.net/user_files/187302.jpgThat is not BURST. That is the TRUE speed files are called and ready based on the transfer size as it increases, therefore @ 256K I am not running 114MB/s, I am running just over 260MB/s for FSX and that means little or no scenery boundary or tile stutters when they are called/recalled. On top of that, the 256MB DDR2 533MHz on-card RAID memory keeps files in que as I make turns and move through high impact scenery areas in a flight, therefore, the RAID card has them ready for system memory for instant recall, and, they do not need to be recalled from the hard drives in the array effectively reducing the real world CPU utilization, further.I wish to make something perfectly clear about the results above.. just because you may have a 300+MB/s rating in a professional benchmark tool does not mean the array is optimal for use with FSX. If the STRIPE size is LOW and the CPU utilization is HIGH, it will kill FSX performance no matter how fast the array is in a benchmark.:)

thanks for clearing that up nickn. You make a clear point about the cpu utilization and that going back to standard sata would be more beneficial. so my question is...what is the benefit at all of motherboard raid? Is it a technology flaunted to the masses? hype? and also on windows format it doesnt give you choices for 256k or 128k it goes from 64k to 512k for unit allocation size (same thing right?)how do we determine what size cluster is better for FSX? what size files does FSX process? and do they vary in size?btw here is my same setup as before with your benchmark

That looks right for motherboard RAID. Your read speed in line with the buffer to disk speed of the RAPTORSEach RAPTOR has a buffer to disk spec of 85MB/s. In real world terms and with the right access spec math applied that works out to be right around 70MB/s so 2x that is 140MB/s. You are losing a bit of performance somewhere, and that would be in the STRIPE most likely, or, the RAID driversThe true RAPTOR data throughput (copy/paste a large folder of files 1GB+ in size form RAPTOR-A to RAPTOR-:( is right around 34-37MB/sA hardware RAID solution with the right STRIPE increases the speed because there is no software between the drive and the bus, and, the memory on the card buffers calls further, increasing the read/write speed significantly. Because everything is done in hardware the CPU is not polled and therefore you get true, clean, solid throughput.Change the block size? If you are speaking to RAID, BLOCK and STRIPE is the same thing. The only way to change BLOCK or STRIPE is to wipe out the array and rebuild it. STRIPE/BLOCK can only be changed during the array build and once it is set it can never be changed without destroying the array and starting over.

hmm interesting.im wondering what to do?I have nvidia nforce590 chipset updated to latest drivers.should I wipe it out and change to 256k blocksize? (can this even be done with my chipset controller?)or like your suggestion earlier just do 2 raptors without raid. and 256k blocksize right? dont most people agree 128k is better for gaming in general?

The larger the BLOCK/STRIPE the better for RANDOM ACCESS, meaning, the higher that value based on the average file size, the better your performance.There is absolutely no such thing as a generic value for STRIPE/BLOCK that is best. That number is calculated based on the real use and application.The rest is a myth and perpetuated by people who do not know any better, and, usually because they rely on silly tools like HD Tach instead of a professional BM tools. There is also more to understanding what is best and what is going on than using ATTO Mark as I did too. If it were me, the generic size I would use over everything else is 256K unless I was setting up a A/V production rig and then I would set it to 2 or 4KThere is no block size involved with a non-RAID HDD setup. BLOCK/STRIPE are pure RAID terms.As for if your RAID array BIOS has the ability to set a 256K STRIPE/BLOCK when an array is created, that I do not know. Your motherboard manual should show that or if there is nothing on the array right now it only takes a few minutes to destroy/rebuild it and find out in the process. It should offer you the option. Read the motherboard manual to find out where that option may be located.I would not use motherboard RAID even if it does.. its killing the CPU. Motherboard RAID is BS the motherboard companies have pushed on the market for so long, everyone believes it

ok thanks nick. you really know your stuff man. I will toss the raid.

You may be confusing CLUSTER format size with BLOCK. When a drive is formatted in Windows it may ask you what CLUSTER size you wish to use. The default is 4K and you can not under any circumstances format a Windows install partition/drive to anything other than 4K or the OS will not bootIf Windows is not going to be installed on the drive, and, the drive is to be used for storage or other you can format it with a larger cluster.. WARNING: When you use a larger cluster size in formatting you LOSE drive size. That amount is based on the size of the cluster you use. At 4K this size is minimal however at the MAX of 64K that loss can be significant. the larger the drive, the more is lostNow, I DO use 64K for my RAID and other (non Windows boot drives) for a reason... 64K cluster format drives do not fragment any where near as much as a drive formatted to 4K. I don

yes your right Im confusing those things. thankyou soo much for your help with this. very insightful. you have opened a new world for me in computer technology.so just to recap. Im doing a normal windows install(no raid as that eats processor)install windows as usual.(there will be no option for block size obviously as there is no raid enabled)and set my FSX HD as 64k cluster size. and run the defrag with name with a comp restart in between each of the 3 runs. roger that. just typing into my "head" memory lol.

Excellent Information... Thanks for pointing me here Nick.Fwiw, I found ATTO Bench32 v2.42 at the ATTO website.Rob

nick to clarify, what is the cluster(not block) setting for fsx drive?4k16k32k64k512K1024k2048k4096k8192khere is vista 32bit(no raid) with hd tach BS program. notice how much my cpu usage went down! but look at my transfer speeds from this one and then the other test:((was reading about 120Mb/s before)and atto as well showing my lack of disk speed compared to before.(was reading about 120Mb/s before) so in conclusion I have lost roughly half my disk bandwidth at most 12%cpu savings though.

4096 is a 4K Cluster format and the default Windows cluster sizeYou can not format to 64K unless you use a 3rd party disk management software such as Acronis Disk Director. As mentioned, 64K is not necessary and it will not increase performance, only reduce fragmentationYou are not testing a RAID array for file chunk calls, switch the TOTAL LENGTH in ATTO to 32MBThe SATA drivers will also influence the result. Make sure you have the most up to data driver for your motherboard.What you dont see with benchmarks is the latency the RAPTOR does not suffer from compared to other drives because of the 10,000RPM platter rotation and the access specs. You have not lost anything.. you have gained 12% of your CPU back, and, I told you the buffer to disk real world on a RAPTOR is about 65-70MB/s. The max is 80-85MB/s. The test show that is correct although a tad low in ATTO, switch the length and retest.And remember, FSX is not a sequential read file system, its a random access file system. Between the CPU that was recovered and the lower access the system will have on the single RAPTOR without the software RAID in the way, FSX will run much better.