RAID0 stripe size & impact on load times/blurries

[Guest Sascha Henken]

>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

[GaryGB 10]

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