Sign in to follow this  
GaryGB

RAID0 stripe size & impact on load times/blurries

Recommended Posts

In trying to solve the blurries I did many tests/tweaks and was experimenting (amongst others) with RAID 0 stripe size. I have 2x74 GB 10K Raptors running with a P5B Deluxe using Intel's RAID 0 SATA controller.I use photo scenery which has loads of small BMP texture files of 44 KB each.I initially had the RAID setup with default stipe size of 128KB. Load times were very long (4 minutes in the photo scenery areas). I then made a copy of my RAID partition (using Ghost), erased the RAID 0 partition and re-created it with a stripe size of 8K. I ghosted back my partition and for exactly the same saved flight load times have been almost halved.Unfortunately it hasn't helped the blurries that are caused by texture loading issues and some sort of CPU contention in SP1 (so I reverted to RTM)Nevertheless, for those of you running RAID0 arrays, I thought you might be interested... For all the others (the majority) who don't have RAID0 sorry this post is not relevant.JC

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I have RAID 0 Raptor 150X2 + non raptor 250Gig X 2 in RAID 0 and O&O defraged alphabaet sorted and what not. Blurries problem doesn't seem to go away.Its the CPU. When I add a payware aircraft like the Lvd D 767 instead of the default aircrafts, it makes it worse. When I add Ultimate Terrain with more details, it has added to the problem. I have AI traffic set at 20% and most of the sliders to around 70-80% Water at 2.Low. Even with the 3.4OC Dual Core E6600, it has not helped. I have 10-15FPSI am convinced, we would need a 15Ghz CPU.Manny

Share this post


Link to post
Share on other sites

Greetings JCThis is very interesting. Have you tried any other sector sizes? Did you defrag your disk before the 128KB test? How did your arrive at 8K?I have 2 x 150Gb Raptors and would like to give this a try. If you have not tried any further tests, I may take a day and go through various sizes. Can you tell me what performance tests you ran in order to measure your results.

Share this post


Link to post
Share on other sites

Very interesting to me as another user of a 4-drive RAID 0 trying to achieve shorter FS load times!I have often wondered about what the optimum FS configuration might be using different RAID 0 array stripe data block or "chunk" sizes with FS9 and FSX to get the best FS base and Flight load times with both a default FS scenery mix versus a Photoreal mix of MegaScenery, VFR-UK etc.Looking forward to hearing more on this (gotta' get a big enough 2nd backup drive to accomodate my entire 800 GB RAID 0 array before I try this again.)Thanks for sharing your insights on this!:-) GaryGB

Share this post


Link to post
Share on other sites

I've heard 32Kb or 64KB stripe size works well for applications requiring a decent rate of HD access.I can't remember where I read the article but they seemed to know a lot more than me on the subject.My raid 0 is at 32 kb stripe size (hitachi deskstars 300GB each)6600 OC at 2.8GHz8800 768MB3GB OCZ 8500 RamP5N 32 SLI plus MBI run FS9 and FSX very satisfactorily.I don't suffer the blurries in FSX like so many of our fellow simmers.Hope this helps.Stu

Share this post


Link to post
Share on other sites

Todd,Yes the disk was defragged when I was on the 128KB stripe size. Going to 8KB really improved things. I haven't tried other sizes and probably will not because ghosting the entire partition takes time and is also aways a little risky...Edit: Load times measured for the same saved flight. I went from 4:02 minutes to 2:20 minutes.Rgds,JC

Share this post


Link to post
Share on other sites

Here's the reasoning... My texture files are 44 KB.With a 128KB stripe size a texture file only resides on one HD so there is not really any RAID induced performance benefit when FS tries to read the file.With a 8 KB stripe size the same 44 KB file is split between the 2 disks with 5.5 segments. So when the file is read by FSX it is coming from 2 disks hence the performance benefit.JC

Share this post


Link to post
Share on other sites

Same deal with me, any add-ons I've installed into FSX seems to degrade performance along with increasing the blurries an extending the time it takes for the blurries to become clear.Everyone can keep blaming hardware all they want, but it's not the root of this problem and tossing more hardware at it certainly isn't the solution either.I've run FSX on extremely overclocked (liquid nitrogen with a host of very custom voltage modifications) equipment that is real world 3X faster than the current top end hardware and it's still slow, still blurry.So whatever hardware requirements FSX requires is certainly a good 3-5 years away. They should have just re-written FSX from ground up and done it right the first time. Same goes with Vista. I'd gladly dump backwards compatibility for a better performing product rather than a compromised product that doesn't really get the job done (same for Vista). If people MUST have compatibility with prior software, make dual boot easy to setup and use. Apple make it easy, why can't Microsoft?

Share this post


Link to post
Share on other sites

I have 2 x 150 GB Raptors. But I don't use RAID. I have FSX on the system drive and add-on scenery (Horizon Simulations UK photorealistic scenery, all 3 volumes) on the second drive. Load times, even with the many small files of photorealistic scenery, are fine. I don't have a problem with blurries with the default scenery at normal to dense autogen settings.I think CPU speed is much more relevant to the blurries than HDD speed, otherwise folks with old IDE drives would be screaming by now. For the record my FSX installation is default (no tweaks) other than the scenery mentioned above and a bunch of aircraft. I'm very careful about keeping my system free of extraneous files (ccleaner), spyware (ad-aware) and defragged (3 x default defraging tool, then re-boot). I run antivirus all the time but I use NOD32, which has a relatively small system footprint.One tip that I have found very useful is to run the default check disk utility say once month. Many issues seem to disappear afterwards but I'm afraid most people tend to forget that it is even there.Cheers,Noel.

Share this post


Link to post
Share on other sites

wow, 4 drives running RAID0!!! You might as well just dunk them in water while you're at it.

Share this post


Link to post
Share on other sites

"They should have just re-written FSX from ground up and done it right the first time."If it were that easy, it would have been done a loonnggg time ago.Thomas[a href=http://www.flyingscool.com] http://www.flyingscool.com/images/Signature.jpg [/a]I like using VC's :-)N15802 KASH '73 Piper Cherokee Challenger 180

Share this post


Link to post
Share on other sites

>wow, 4 drives running RAID0!!! You might as well just dunk>them in water while you're at it.Hi Big Al:I wasn't quite sure what you meant... care to elaborate? :-hmmm GaryGB

Share this post


Link to post
Share on other sites

Hi JC,I'm been away for a while and just catching up on FSX stuff.It looks like you maybe had the RAID0 array not for the OS, as you were able to ghost FSX back- is that correct? I have a 2* RAID0, but everything including the OS is on the array (with 128 stripes I might add :) ). I don't know how I would do what you have done when I would effectively destroy the only HD array until I had it reconfigured and had been able to ghost the data back- or where I would put the ghosted image between re-striping :)Thanks- Bruce.

Share this post


Link to post
Share on other sites

After following this thread I really started to reconsider NOT to use RAID0 anymore cause it makes no sense to use RAID0 on normal desktop systems where mainly games are beeing played with. I was convinced by several german forum resources but also from a long Anandtech story about RAID0 with a WD Raptor:http://www.anandtech.com/showdoc.aspx?i=2101&p=5Interesting were for me page 10 to 11 (Final Words):If you haven't gotten the hint by now, we'll spell it out for you: there is no place, and no need for a RAID-0 array on a desktop computer. The real world performance increases are negligible at best and the reduction in reliability, thanks to a halving of the mean time between failure, makes RAID-0 far from worth it on the desktop.To believe or not to believe. I

Share this post


Link to post
Share on other sites

Hi Again: :-wave I believe the idea we are reaching for with RAID 0 in FS is to simply shorten load times for FS itself and/or a flight, rather than a theoretical sustained read+write throughput usually considered desirable or necessary for special types of server setups different than might apply to an FS system.If I understand correctly from the info I have seen in FS forum posts, once most of the code for an FS flight is up in RAM and/or VRAM, intermittent drive access for my style of a VFR/GA low-and-slow flight is not going to show a benefit from a 2-drive RAID 0 array much more than it would from a single properly de-fragged 7200 RPM Ultra-ATA/133 or SATA 150/300 mbps drive.What I'm personally after (initially at least) is to shorten those coffee breaks and naps I seem tempted to take during load times with FS! :-lol I can already report that with my 4-drive RAID 0 array in even a default 64K stripe block or "chunk" size, I do get faster load times than in a non-RAID 0 configuration, which is why I built the array to begin with... Oh, and I don't even have to "water cool" my drives! ;-) I would like to hear what others have to say about their results using RAID 0 array stripe block or "chunk" sizes to accommodate FSX file reads which appear in Filemon logs during FS app loads and then flight loads with consideration of:1. Greater numbers of accesses for a given file size range2. More frequent accesses for a given file size range3. Longer duration of access for a certain file size rangeIf it is sufficiently motivating to anyone willing to test this with FSX, it would be helpful to know also what the difference is between:1. A default FSX scenery mix load2. A FS9 SDK-compliant "lots-of-smaller-files" photorealistic scenery load2. A current FSX SDK-compliant "fewer-but-bigger-files" photorealistic scenery load(All above based on results logged in Filemon.)This might help us to see if there might be a preference as to RAID 0 array stripe block or "chunk" size to be chosen when setting up a system to be used primarily for FS (...the way we want it to run for our very own purposes).BTW: I wonder just how hot it gets in the computer case with FSX loading off 4 - 10,000 RPM or 4 - 15,000 RPM higher performance RAID drives? :-eek GaryGB

Share this post


Link to post
Share on other sites

>Hi Again: :-wave >>I believe the idea we are reaching for with RAID 0 in FS is to>simply shorten load times for FS itself and/or a flight,>rather than a theoretical sustained read+write throughput>usually considered desirable or necessary for special types of>server setups different than might apply to an FS system.>>If I understand correctly from the info I have seen in FS>forum posts, once most of the code for an FS flight is up in>RAM and/or VRAM, intermittent drive access for my style of a>VFR/GA low-and-slow flight is not going to show a benefit from>a 2-drive RAID 0 array much more than it would from a single>properly de-fragged 7200 RPM Ultra-ATA/133 or SATA 150/300>mbps drive.>>What I'm personally after (initially at least) is to shorten>those coffee breaks and naps I seem tempted to take during>load times with FS! :-lol >>I can already report that with my 4-drive RAID 0 array in even>a default 64K stripe block or "chunk" size, I do get faster>load times than in a non-RAID 0 configuration, which is why I>built the array to begin with... Oh, and I don't even have to>"water cool" my drives! ;-) >>I would like to hear what others have to say about their>results using RAID 0 array stripe block or "chunk" sizes to>accommodate FSX file reads which appear in Filemon logs during>FS app loads and then flight loads with consideration of:>>1. Greater numbers of accesses for a given file size range>2. More frequent accesses for a given file size range>3. Longer duration of access for a certain file size range>>If it is sufficiently motivating to anyone willing to test>this with FSX, it would be helpful to know also what the>difference is between:>>1. A default FSX scenery mix load>2. A FS9 SDK-compliant "lots-of-smaller-files" photorealistic>scenery load>2. A current FSX SDK-compliant "fewer-but-bigger-files">photorealistic scenery load>>(All above based on results logged in Filemon.)>>This might help us to see if there might be a preference as to>RAID 0 array stripe block or "chunk" size to be chosen when>setting up a system to be used primarily for FS (...the way we>want it to run for our very own purposes).>>BTW: I wonder just how hot it gets in the computer case with>FSX loading off 4 - 10,000 RPM or 4 - 15,000 RPM higher>performance RAID drives? :-eek >>GaryGBHi Gary,interesting read there :)yesterday night I took my time to erase my RAID0 array (with 2 disks) and started with NCQ native SATA mode so right now i

Share this post


Link to post
Share on other sites

Hi Sascha:Thanks for the continued dialog and exploration of this RAID 0 topic; we may still do well to inquire into and learn more about it for improving load time in FS. :-) The article you cited was indeed an interesting and detailed exploration of RAID options available for consumer grade desktop systems.As you pointed out, one's Filemon results should be objectively correlated with quantifiable HD throughput results in a reliable utility such as you mentioned in order to gauge whether there can be meaningful improvements on one's FS system using RAID 0 capable controllers in custom configured stripe block/chunk sizes.And of course, since a RAID 0 drive appears as a "single drive" to DOS, Windows and nearly every OS or application except very special utilities, it should be treated as a single drive... that needs to be kept backed up like any other single hard drive. That to me effectively makes it irrelevant whether one's risk for individual drive component failure resulting in loss of the entire RAID 0 striped array is increased by adding more drives to the component size of a given array at build time.If one stops to think about it, either one is doing backups... or one is not! Any drive can fail at any time right out of the box, and I've had it happen. Heaven forbid it should happen to anyone else, but if it does, they might yet be able to avoid panic and/or shelling out big money to an opportunistic recovery company who may not always actually do very much work in exchange for their high fees to recover data that the end user themselves might have recovered. Hopefully at such a time an unfortunate "backup roulette gambler" might learn a lesson for the rest of their lives as a computer user about the importance of doing backups; perhaps too they will learn about automating their redundant backups via multiple hard drives, and NOT just on equally vulnerable removable media that may not even get byte-for-byte compared with the original source (most backup software just does a total byte count comparison!) ...much less restore-tested after writing/burning. ;) Anyone faced with this failure and recovery dilemma or otherwise interested in reading the sordid details (and happy ending!) of my own such humbling lesson can do so here: http://forums.simflight.com/viewtopic.php?t=49551Anyway, that is why I am waiting to further test my 800 GB RAID 0 configuration options until I have yet another large redundant backup hard drive in my system, as I just won't allocate the time anymore to sitting there handling even dual layer removable DVD media to make "extra" incremental backups, and worse yet to restore them if my backup drive (single physical drive... not RAID array) fails.Hmmm... lets see: 800 GB at 8.5 GB max per backup dual media DVD = over 94 DVDs; I'd rather install another redundant backup hard drive and let software do the grunt work automatically!:-rollIMHO, life is just too short for doing MANUAL backups on removable media for anything more than an initial archival backup copy of software and core user data; incremental backups might best be done on redundant hard drives. Removable media backups should IMO be byte-for-byte compared with the original source, and restore-tested promptly after written/burned. ;) Well, lets hope the dialog and testing continues here; not having higher speed drives, I believe many of us would still be interested in seeing what FS load time results come about with different stripe block/chunk sizes on RAID 0 arrays using 10,000 RPM fast access speed drives!:DGaryGB

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this