Best Hd Partition Setup For Fs

[fwerff 70]

Expanding my harddisc capacity by adding another 320Gb disc.Combined with the other discs already in, this will give me2x 160Gb in Raid 0 and 2x 320Gb in Raid 0.With two raid arrays, I need to choose my setup for the partitions.Right now I'm thinking the following:Array 1 (2x160):C-partition: 50Gb for OS + System Tools + Page FileD-partition: 170Gb for FS9 sceneryArray 2 (2x320):E-partition: 100Gb for FS9 (except scenery) + FS related progsF-partition: 200Gb for FSX (FS9 is still my main sim due to hardware constraints)G-partition: 100Gb for office progsH-partition: 240Gb for data (MyDocuments, photo's and video's)What I'm wondering about most is the location of the FS9 scenery. I want it on a separate drive, controled by a separate controller. This will give me the highest performance gain. What I don't know is how much the system needs the Windows System files while FS is running. If the system is constantly swapping between C and D, I can imagine this will cost a lot of performance.So should I then put Windows and FS9 on the same partition?Thanks for the advice!Best regards,Frank

[Guest D17S]

Sounds like fun, but that additional complexity won't help FS in-gameplay. A single modern 7200RPM HD is entirely adequate to provide FS 100% of a storage system's contribution to in-gameplay. Raids and raptors just are not necessary. The raid/raptor (fiber channel?!) setup will provide a quicker initial FS program load and then initial flight loads . . . but only by a couple of seconds. After the 1st load, Vista does some magic and raid-or-raptor vs non-raid-or raptor make no difference, even there. Some arguments might suggest that these modern 7200 RPM drives will cause ingame scenery loading stutters. Not so. This is still a CPU Horsepower (i.e., processing) issue. The best HD optimization is to use a single HD for everything, then a modern defragger to position the FS directory (s) to the outer edge of the single HD. Any additional drives might provide more value as a system/data backup destination.

[Guest Nick_N]

Expanding my harddisc capacity by adding another 320Gb disc.Combined with the other discs already in, this will give me2x 160Gb in Raid 0 and 2x 320Gb in Raid 0.With two raid arrays, I need to choose my setup for the partitions.Right now I'm thinking the following:Array 1 (2x160):C-partition: 50Gb for OS + System Tools + Page FileD-partition: 170Gb for FS9 sceneryArray 2 (2x320):E-partition: 100Gb for FS9 (except scenery) + FS related progsF-partition: 200Gb for FSX (FS9 is still my main sim due to hardware constraints)G-partition: 100Gb for office progsH-partition: 240Gb for data (MyDocuments, photo's and video's)What I'm wondering about most is the location of the FS9 scenery. I want it on a separate drive, controled by a separate controller. This will give me the highest performance gain. What I don't know is how much the system needs the Windows System files while FS is running. If the system is constantly swapping between C and D, I can imagine this will cost a lot of performance.So should I then put Windows and FS9 on the same partition?Thanks for the advice!Best regards,Frank

FrankShould you wish to review storage system information in reference to use with FSX, which is different than FS9, please read this posthttp://forums1.avsim.net/index.php?s=&...t&p=1510165If you use that advice, you will can figure out where you stand with your hardware and make changes in order to obtain the best resultand DO be aware that NCQ and the advanced SATA enabled in the BIOS will SLOW Raptors and performance drives DOWN. Its a great feature for network systems but not so great for gaming systems which poll the drives and need every cycle they can get made available to them for reducing CPU overhead.

[fwerff 70]

....Vista does some magic and raid-or-raptor vs non-raid-or raptor make no difference, even there. Some arguments might suggest that these modern 7200 RPM drives will cause ingame scenery loading stutters. Not so. This is still a CPU Horsepower (i.e., processing) issue. ...

Thanks for your input. Still wondering about two things...I probably should have mentioned it, but I'm still running on good ol' XP and I don't know if that magic your talking about is also available in XP...Second; when I fly at cruiselevel, using FSGlobal 2008 and Ultimate Terrain, the HD LED indicator is flashing almost continuously. Especially around mountens I generally get more blurries than I consider acceptable.True that within FS9/FSX the CPU plays a major part, but with the non-stopping LED flashing, couldn't it mean that my HD has problems in keeping up?My system holds an AMD Athlon FX-60 at 2.8GHz and 2Gb of fast RAM, which should be sufficient to run FS9 in all its glory.Regards,Frank

[fwerff 70]

FrankShould you wish to review storage system information in reference to use with FSX, which is different than FS9, please read this posthttp://forums1.avsim.net/index.php?s=&...t&p=1510165If you use that advice, you will can figure out where you stand with your hardware and make changes in order to obtain the best resultand DO be aware that NCQ and the advanced SATA enabled in the BIOS will SLOW Raptors and performance drives DOWN. Its a great feature for network systems but not so great for gaming systems which poll the drives and need every cycle they can get made available to them for reducing CPU overhead.

Thanks! I will dig into it...Given that FS9 is my primairy sim, do you know a similar post for FS9?Best regards,Frank

[Guest D17S]

Modern imaging tools make it easy to run your own experiments. You can check out what's what for yourself. Get a flight setup and saved. Now fly the pattern and and get a feel for the visuals. Run the frame counter. With an adequate Vcard (8800GT and above) you will generally see the frame counter at high FPS, but the visuals are obviously not that high. That's the Vcard simply repeating the same frame because the CPU cannot process new data (and thereby feed the Vcard that new data) fast enough. The Vcard will repeat the same frame while it waits. To the Frame counter, a frame is a frame, new or not. The frame counter will zoom along, but the visuals will display the infamous stutters. But check it out. Maybe the bottleneck is further upstream. Maybe the HD is not feeding the processing system data fast enough. Maybe it's actually the CPU (processing system) that is being starved by lack-O-data from the storage system. I've found this is not the case. You may get the same result. After your test flight with the current raid setup, image your system to the new single 320. Boot off the 320, defrag the FS directories to the outer edge of the HD and run it again. Your raid was transferring at ~ +150 MBs while the single will be at +75Mbs. That's slashing the transfer rate by about 1/2. Did it matter? If you want to experiment with a raptor, snag one and repeat the drill. The raptor's advantage is better access time. However consider: A drive's access time is integral to its transfer rate. Any drive must find the data (access time) before it can transfer the data (transfer rate). Does access rate really matter beyond a drive's ability to actually transfer that data? What's cha get? Now you know. If nothing else, it's great fun to play with the 'puter.

[GSalden 4,657]

Modern imaging tools make it easy to run your own experiments. You can check out what's what for yourself. Get a flight setup and saved. Now fly the pattern and and get a feel for the visuals. Run the frame counter. With an adequate Vcard (8800GT and above) you will generally see the frame counter at high FPS, but the visuals are obviously not that high. That's the Vcard simply repeating the same frame because the CPU cannot process new data (and thereby feed the Vcard that new data) fast enough. The Vcard will repeat the same frame while it waits. To the Frame counter, a frame is a frame, new or not. The frame counter will zoom along, but the visuals will display the infamous stutters. But check it out. Maybe the bottleneck is further upstream. Maybe the HD is not feeding the processing system data fast enough. Maybe it's actually the CPU (processing system) that is being starved by lack-O-data from the storage system. I've found this is not the case. You may get the same result. After your test flight with the current raid setup, image your system to the new single 320. Boot off the 320, defrag the FS directories to the outer edge of the HD and run it again. Your raid was transferring at ~ +150 MBs while the single will be at +75Mbs. That's slashing the transfer rate by about 1/2. Did it matter? If you want to experiment with a raptor, snag one and repeat the drill. The raptor's advantage is better access time. However consider: A drive's access time is integral to its transfer rate. Any drive must find the data (access time) before it can transfer the data (transfer rate). Does access rate really matter beyond a drive's ability to actually transfer that data? What's cha get? Now you know. If nothing else, it's great fun to play with the 'puter.

My new system has a 1 TB 32mb cache drive for the OS, FSX and all addonsBeside that one 500 GB drive for backup.recently I had the opportunity to contact a MS FS simulator consultant and asked what would be better : one 150Gb Velociraptor for the OS and one 300Gb Velociraptor for FSX and addons. Or 2 Velociraptors in Raid 0.To my surprise he replied that it was best to use a single 1 Tb drive with 32mb cache drive.In that way I woul have the most fluid Fs experience.....According to him FSX does not run optimal when using a Raid setup and using two seperate drives for the OS and FSX wasn't the best to do either.

[tfm 169]

My new system has a 1 TB 32mb cache drive for the OS, FSX and all addonsBeside that one 500 GB drive for backup.recently I had the opportunity to contact a MS FS simulator consultant and asked what would be better : one 150Gb Velociraptor for the OS and one 300Gb Velociraptor for FSX and addons. Or 2 Velociraptors in Raid 0.To my surprise he replied that it was best to use a single 1 Tb drive with 32mb cache drive.In that way I woul have the most fluid Fs experience.....According to him FSX does not run optimal when using a Raid setup and using two seperate drives for the OS and FSX wasn't the best to do either.

That advice is probably perfectly sound and admittedly one quickly reaches the stage of arguing about the number of angels dancing on a pinhead. But IMHO it somewhat over-simplifies matters.RAID can be a handicap if you use onboard controllers, for two main reasons. First, they tend to use CPU cycles to work their magic, thus harming FSX performance. Secondly, the stripe size on an onboard controller is unlikely to exceed 128k. By contrast, if you have a decent dedicated RAID controller, the CPU overhead is minimal and you should get access to 256k stripes for your array. The returns - though not breathtaking - are (IMHO) worthwhile up to a 2 disk RAID0. For arrays with more than 2 disks, the equation starts to get complicated because although RAID0 delivers faster transfer rates (making fuller use of the available bandwith on the transfer bus) it can actually make latency worse. In my case, three disks in RAID0 gives no real advantage over two: presumably, the extra transfer rate is cancelled out by the slower latency. But the first two disks in RAID0 do give a nice little extra boost: presumably, the extra transfer rate brings a bigger boost than is lost by the diminished latency. The extra bandwidth available through a decent RAID0 setup will definitely reduce load-times and, to a degree, it may also reduce the risk of stutters. BUT note two points: (i) stutters are seldom a result JUST of your hard disk setup: they are usually caused by a combination of things of which a sub-optimal hard disk setup may or may not be a contributing factor; and (ii) in my experience, if the hard disk setup is contributing to stutters then the most probable cause is not (or not just) transfer rates, but latency: ie, read/write access times. You get the best latency by going for fast-spinning drives with high-quality heads with decent control circuity - and then pushing all your speed-critical data to the edge of the platter in alphanumeric order using a suitable defrag utility. The best candidates are SAS drives at 15k RPM; but SATA II drives at 10k RPM are a decent alternative, of which the Velociraptors are the main if not the only current examples. All generations of Velociraptors seem to have reasonable spin speeds and heads, but there appear to be variations in the quality of the control circuitry: the latest generation, by many accounts, gets the mixture right.For the same reason, I would also steer away from large, slow hard disk drives with larger amounts of cache RAM. A large cache might help with other applications, but the most reliable sources on this forum indicate that a large cache can't lift the performance - for FSX purposes - of a 7200rpm drive into that of a 10k rpm drive, much less a 15k rpm drive. This probably has to do with FSX not calling files in the particular way that large caches can help with: see, for some possible clues, http://en.wikipedia.org/wiki/Native_Command_Queuing.What that all amounts to is that you will probably be better off paying less attention to cache size and concentrating on one fast drive dedicated to FSX so that you can push all the FSX stuff to the outer edge of the platter and keep it there without other applications or the OS trying to elbow their way in. Upto 2 fast drives in RAID0 are a "deluxe" option if you're willing to use a decent plug-in controller that offers 256k stripes: otherwise, RAID0 may indeed prove to do more harm than good. Put bluntly: if it were my money, I'd stick with your first instinct: from the latest generation of kit, a 150Gb Vraptor for OS etc and a 300Gb Vraptor for FSX.Tim

[Guest Nick_N]

That advice is probably perfectly sound and admittedly one quickly reaches the stage of arguing about the number of angels dancing on a pinhead. But IMHO it somewhat over-simplifies matters.RAID can be a handicap if you use onboard controllers, for two main reasons. First, they tend to use CPU cycles to work their magic, thus harming FSX performance. Secondly, the stripe size on an onboard controller is unlikely to exceed 128k. By contrast, if you have a decent dedicated RAID controller, the CPU overhead is minimal and you should get access to 256k stripes for your array. The returns - though not breathtaking - are (IMHO) worthwhile up to a 2 disk RAID0. For arrays with more than 2 disks, the equation starts to get complicated because although RAID0 delivers faster transfer rates (making fuller use of the available bandwith on the transfer bus) it can actually make latency worse. In my case, three disks in RAID0 gives no real advantage over two: presumably, the extra transfer rate is cancelled out by the slower latency. But the first two disks in RAID0 do give a nice little extra boost: presumably, the extra transfer rate brings a bigger boost than is lost by the diminished latency. The extra bandwidth available through a decent RAID0 setup will definitely reduce load-times and, to a degree, it may also reduce the risk of stutters. BUT note two points: (i) stutters are seldom a result JUST of your hard disk setup: they are usually caused by a combination of things of which a sub-optimal hard disk setup may or may not be a contributing factor; and (ii) in my experience, if the hard disk setup is contributing to stutters then the most probable cause is not (or not just) transfer rates, but latency: ie, read/write access times. You get the best latency by going for fast-spinning drives with high-quality heads with decent control circuity - and then pushing all your speed-critical data to the edge of the platter in alphanumeric order using a suitable defrag utility. The best candidates are SAS drives at 15k RPM; but SATA II drives at 10k RPM are a decent alternative, of which the Velociraptors are the main if not the only current examples. All generations of Velociraptors seem to have reasonable spin speeds and heads, but there appear to be variations in the quality of the control circuitry: the latest generation, by many accounts, gets the mixture right.For the same reason, I would also steer away from large, slow hard disk drives with larger amounts of cache RAM. A large cache might help with other applications, but the most reliable sources on this forum indicate that a large cache can't lift the performance - for FSX purposes - of a 7200rpm drive into that of a 10k rpm drive, much less a 15k rpm drive. This probably has to do with FSX not calling files in the particular way that large caches can help with: see, for some possible clues, http://en.wikipedia.org/wiki/Native_Command_Queuing.What that all amounts to is that you will probably be better off paying less attention to cache size and concentrating on one fast drive dedicated to FSX so that you can push all the FSX stuff to the outer edge of the platter and keep it there without other applications or the OS trying to elbow their way in. Upto 2 fast drives in RAID0 are a "deluxe" option if you're willing to use a decent plug-in controller that offers 256k stripes: otherwise, RAID0 may indeed prove to do more harm than good. Put bluntly: if it were my money, I'd stick with your first instinct: from the latest generation of kit, a 150Gb Vraptor for OS etc and a 300Gb Vraptor for FSX.Tim

Awesome post Tim

[Guest Nick_N]

Thanks! I will dig into it...Given that FS9 is my primairy sim, do you know a similar post for FS9?Best regards,Frank

Same thing Frank... That list is good for both FS9 and FSX however with FS9 and because of the much smaller file size in FS9, and, assuming addons will follow the same file scale in their design you can get away with motherboard RAID0 but I would not go with more than 2 drives in that array. Motherboard RAID is a CPU killer and each drive accessed in the array pulls more and more from the CPUIf RAID0 is implemented on a professional hardware RAID card solution, that’s different. The card then removes the load off the CPU. A good card is not a 100-150 dollar solution. The cards that truly offload the CPU have on-card memory in amounts ranging from 256-512MB In the case of FS9 you want a STRIPE of 64 to 128 depending on addons. If its just FS9 then 64 would be a better STRIPE choice however with addons moving that to 128K is betterWith FSX its suicide to run less than a 256K STRIPE and if on a motherboard controller you will be killing CPU cycles that FSX needs. FSX places nearly a 80-100x demand on the CPU over FS9 and therefore every single CPU cycle you can recover from a 'smart' storage solution choices will provide a gain for the titleCarry that down to FS9 as well. Although not as demanding as FSX everything you do to optimize that area the old rendering engine will gainalso... you should not ever partition a performance RAID array. Partitions are for backup and storage drives, not performance application drives and arrays. And always try to maintain 40% or greater freespace with all software installed on any performance storage solution. Once you cross the 40% threshold, performance begins to drop quickly. I like to try and maintain 50% at min.

[Guest D17S]

Aside from all this advice, there's no need to - Believe - anyone. The proof is Still in the pudding. Try it on the single 7200, then a raid, then a raptor. See what you get.

[Guest Nick_N]

One major downfall with forums is there are some people who have never actually used (or correctly used) any of the storage hardware we have been discussing in this thread in application, ever,... but instead have opinions which are not based in any solid tech. They sometimes do not understand why they may see one result or another.In that, Tims statement is very true stutters are seldom a result JUST of your hard disk setup: they are usually caused by a combination of things of which a sub-optimal hard disk setup may or may not be a contributing factor; and (ii) in my experience, if the hard disk setup is contributing to stutters then the most probable cause is not (or not just) transfer rates, but latency: ie, read/write access times. Which are also magnified by the supporting hardware installed which is procesing that data and converting it to a smoothly (or poorly) rendered imageGiven what Tim posted, such myths about better storage can be traced back to those who refuse to even try correctly purchasing motherboard and memory product based on real engineering, and, setting it up correctly in a clock. That purchase and setup does not require any 'uber-clocking' since the memory and motherboard product purchased have the ability manufactured into them, and, the motherboard in use has the 'fluff' which are the voltage regulator and filter circuits to accomplish the goals safely, easily and stable. It requires purchase of better than 'mediocre' quality parts.One can take that a step further and apply it to a next gen system in which clocking is not in any way a strain on any part of the system as it may have been with the last generation of components.And then bring it down to the norm and even if one does not clock at all, purchase of the right storage component(s) becomes even more important because the over and above CPU cycles being generated by a clock are not present and the default clock of the CPU is even further eroded away from the application by the storage system in use.As Phil Taylor has posted many times... "you 'do' get what you pay for", however I am going to add something to that statement and say: "If you know what you are doing with it"Use of stopwatch in FSX load times in guessing at storage performance is a utterly ridiculous and completely amateur way to judge the result in use of better storage hardware. Anyone who uses that test and refers to it as a valid test for reporting on storage performance in FSX in compare of different solutions has no real storage performance engineering experience, at all.