Open question(s) regarding performance

[almccoyjr 7]

I know that performance is in the eye of the beholder, but I'd like to conduct some experiments with different installed configurations of BHaH/HitR. They'll be no mods installed at this time.

 

The reason for doing this is singular: my CFO has given me permission to build my new, and most likely, last  system...WOOHOO!!! So I'm doing some experimenting with OFF and Prepar3D to see what performances gains there are in helping me to decide how just high I'm going to jump. I have the scenario for P3D covered. It's OFF I'm trying to setup.

 

I'm going to have 2 install configs:

 

   1) OBDSofware\CFsWW1 Over Flanders Fields located on WD Raptor 1tb hdd F:\

    1.a) WW1Scenery located on WD Raptor 600gb hdd G:\ hardlinked to F:\

 

  2) #1) above

   2.a) WW1Scenery will be located in system memory using a ram drive.

 

The ConfigEditor for all configs will have all sliders at 5 and screen resolution set at 1920 x1200 @32 with anti @ 8 samples. I'm leaving everythin else as is. The Workshop settings will be set for normal/realism and will have to be flown from Quick Combat in order to fly same scenario.

 

All I need now is very stable scenario that I can fly for about ten minutes. It will need plenty of aircraft, scenery, terrain and weather. I would like to be able to fly a short pattern with at least 2 turns. I'll use Fraps to record each flight. I plan on flying five flights for each config in order to generate a decent average.

 

I'm open for suggestions. Is there a particular area, date, time or (?) in the sim that can be setup to meet these requirements?

 

I'll be circling.

 

plug_nickel

 

ps...I thought this might also be helpful to those you have more than one hdd or have at least 8-16gb of ram

[+Erik 1,731]

The best configuration if you can get there.

 

SSD > SATA > CPU > MEMORY to run each processor / core > VIDEO CARD with sufficient memory and processor. Where most people find their bottlenecks are in interface of the disks, cpu memory, video processing/memory.

 

Scenario one makes little sense, unless there's a specific reason for the configuration. If each of the HDD are 7200 rpm you can assume about 100 MB/s throughput and let's say you run them on a SATA interface which will carry 150 MB/s the two disks combined if reading together will flood the SATA interface causing a bottleneck.  Firewire 800 is about 80 MB/s and USB 2 is about 40 MB/s and USB 3 is about 125 MB/s. This problem get's worse if you increase the speed of the disks to say SSD or 10,000 RPM in a multi-drive configuration. In your example it appears you have at least three disks that information is coming from OS, GAME, SCENERY.

 

Scenario two will be faster though you're taking away core memory to create the RAM disk which isn't a wise idea just a cheaper one than actually buying SSDs.

 

Keep in mind most games don't use threading very well, so if you have an 8 core processor most of them will be idle during game play, especially if it's an older game like CFS3 with OFF, etc.

 

In my opinion the most notable differences you'll see are changing your HDD to SSD and getting a better video card, that's assuming you have the mother board and processor(s) to handle the video card upgrade. 

 

Ideally you'll want to benchmark the changes to validate any noticeable improvement. The hardest part about a DIY configuration is knowing what pieces play nicely together and where you can squeeze performance or trade costs. Also all the crazy information you'll get from people like me who each have their own view of what's best. For me I start with what's known (is my cpu slammed, are the disk(s) thrashing due to high read/write, is my video memory buried, etc) and work backwards to get the best solution at the moment for what I want to spend versus what I need to fix.

 

Just my 2 cents on the proposal.

 

Edit** I should also mention that SATA II (300 MB/s) and SATA III (600 MB/s) are more the norm these days depending on your motherboard. 

 

Good luck.

Edited September 18, 2013 by Erik
I'm tired and shouldn't type past midnight. I removed some typos and added info on interface speeds for more SATA II and SATA III that I forgot.

[Tamper 9]

Well, this is certainly an interesting topic for discussion.  Al - whose opinion I have always had considerable respect for - has posted a question that goes a step beyond the arguments about SSDs and hard disks, or even (for that matter) beyond SSDs vs. caching scheme.

 

First things first, let me say that I hope to get adequate time to participate; this is truly an interesting subject but these things usually take so much time...and it's usually not worth it.  Leading a horse to water, and all that.

 

I'd also like to say that, if you're not the type to digest the "walls of text" that often accompany complex subjects, perhaps you're better off staying on the porch.  Worthwhile academic discussions require effort; in forums like this, that means writing and reading at a minimum.

 

That being said, I have learned over time that you (Al) have an affinity for RAM disks.  A good idea, of course, speedy as the day is long - no arguing that RAM is faster than SSDs (and I never have, to haul out a grossly misunderstood topic if there ever was one).  But, let's look at reality:

 

1. Until recently, most motherboards couldn't handle more than maybe 8G.  So, we're really only getting to the point that a RAMdrive is seriously worth considering.  Erik, Al knows plenty about SSDs, but he wants the ultimate in performance, thus the RAM drive.  The first scenario, I think, was included in this basically to show a baseline - and, as he explained, for those who may have a secondary data drive - the idea being to get the textures off the drive OFF is installed on.

 

Not a bad idea, but there is more to cause stuttering in OFF any game than just terrain.  If it were possible, I'd look at trying to load the aircraft skins.  I've thought more than once that things got 'framey' just as other A/C(s) entered view.

 

Anyway, I honestly think that until you get out past 8G, you're not using RAM effectively if it's used for anything other than Windows, and until recently, motherboards didn't support that much...so, in fairness and accuracy, the idea of a decent-sized RAM drive is only recently becoming a viable concept (not counting specialty solutions here).  Even then, TBH, it's still going to be sparse compared to what you can buy in an SSD, dollar-for-dollar (see below).

 

2. A while back (years) I recall having a similar discussion - indeed, where I think I first realized how fond our good friend Al is of RAM drives.  I pointed out another concern at that time: Power.  And therefore, heat.  Perhaps not a show-stopping issue - and it's bottom of the list when we're in pursuit of the fastest performance we can build.  But, it bears repeating:  Unlike conventional hard disks and SSDs, RAM requires constant power to "refresh" its contents.  And, since mankind's current implementation of technology involves electronics that are still fairly lossy, there's a lot of heat generated with all that power.  Although I haven't done the math, It likely pales against the type of video cards a lot of us have...but still, all that heat must be dealt with (requiring more power still to dispatch it).  Packed densely on a motherboard the size of today's, and you can run into some real power management issues...

 

3.  FRAPS?  Interesting choice, because (to me) this whole test is being constructed around the premise of allowing the 'big' textures the fastest access we can - IOW, to me, it *seems* that this is about trying to eliminate stuttering that seems to accompany texture loading.  (Is that even close, Al?)

 

*IF* that's the case, then I'd suggest that FRAPS - or any other tool recording AVERAGE frame rates - is taken with a grain of salt.  Without going into the whole detailed explanation, I'll say that it is undoubtedly the even distribution of frames, not frames-per-second, that will make the difference in the visual perception of "smoothness". When people perceive the 'stutters', it can occur smack in the middle of an otherwise impressive 60+ FPS (average); pausing only for that literal split-second during which the actual "frame rate" dropped very low, but you'd never see it looking at an average FPS.  I'm not even sure that FRAPS (and other tools) can accurately gauge when the 'stutter' occurs.  In fact, the longer you run an average, the more it will obscure these dips and stutters - so I've truly never understood what all the "I get xxx FPS" yelping is about.  I truly do understand that FRAPS is perhaps the only choice, lacking much else by way of frame counting apps...but I prefer to call a spade a spade.  This frame rate thing is the single most misunderstood concept in the entire world of PC gaming, in my eyes.  People go on and on about FPS, when it's easy to prove that no one can tell the difference in two frame rates depending on the circumstances.  IMHO, there should be some way to quantify stuttering, because I suspect that's what most everyone confuses with low/bad frame rates - but I don't think there is such a way.  Al?

 

4. Cost.  This idea that RAM is cheaper?  Whew...RAM these days goes about $9 a gig.  SSDs go around $0.90 a gig.  It doesn't take a rocket scientist to see that - while no one's arguing that an SSD is as fast as memory - SSDs are without question the fastest storage per unit cost, period.  Even with recent increases in the amount of RAM a PC can have, there's not going to be enough RAM to load everything in it, forcing some sort of loading/management scheme (next point).

 

5, Upkeep/setup/maintenance.  While it's conceivable to run a RAM drive for 'major' games by selectively bootstrapping things into a RAM drive (and I think that's what our good friend Al is up to), and it would undoubtedly be fast (yes, even faster than an SSD, of course...), it's going to get tedious if it were to involve more than one game/program.  Many people, I think, might not be able to manage the intricacies of setting all that up (even though it's clearly something Al knows a lot about)...and, in some cases, I'd venture it won't even work - that is, to install a game in a typical fashion and then run it from a RAM drive.  You can't install it on the RAM drive outright, because it's volatile, so it'll need to be 'loaded' into memory (RAMdrive), hence running on a different drive letter than where it's installed, which might cause havoc with some installs...and, since there's only so much memory available for the RAM drive, you'd need a 'runtime' loader for each/every game you wanted to run there...

 

I'll tell you, interestingly enough, I've been faulted a number of times here for my approach to performance...I've been accused of 'throwing money' (which could not be further from the truth) but what I've spent per unit of storage is one-tenth what RAM would cost.

 

I've also been accused of over-complicating things with the arrangements I've used (multi-drive systems, RAID, etc.) but managing all this in a RAM drive would surely take some a lot to keep up with (comparatively, I mean).

 

Al, am I totally off base here ...?  WIll you get the performance I think you're after?  I bet you will; I'd bet further that you wouldn't be trying if you didn't already know you could  :D

 

BTW, what a topic!!  My complements.

Edited September 18, 2013 by Tamper

[almccoyjr 7]

Wow....Thanks for the in depth,  academic & technical responses. I'm still digesting both replies. This will obviously be a work in process and I'll be responding to all points, insights.!

 

Install 1 is to be a base line. No tweaks, mods, ConfigEditor changes or use of nvidia Inspector. Just hardware performance and file placement. I will be using UltimateDefrag to place files specifically on tracks. The reason to use Fraps is to record where and when micro/stuttering or slowdown should they occur during the runs. I'm not interested in fps, but rather in "fprs" or frames per rendered scene. FPS is the basest, most coarse and ultimately, most meaningless measurement you can use.  Fraps does have a negative impact, but the loss can be extrapolated and averaged in. I'd be open to some other method of recording if it would make it easier.

 

I've been away from CFS3 file structure for awhile and am, once again, reacquainting what's what. When I've worked up all the files, my final base line run will have scenery, terrain, flyable & AI aircraft all hard linked on a separate drive. That's my final goal for Install 1. It seems to me that having the core flight engine on one drive,the variables that impact the sim on other, while taking into account where those files are located on both drives seems to be the most efficient way of setting up any simulator, especially a flight sim.

 

SSD's are getting more affordable and thus popular; however, hdd's still outnumber ssd's and many systems have mutiple hdds. So I thought that a test might be of some benefit for those with multiple hdds. It might help the sim to run a little "better" without having to invest in anything else, save for a good defrag program.

 

PCI-e drives, RevoDrive as an example. are much faster than a ssd, but are extremely expensive when you start getting into the range of 480gb or larger. For the price of a RevoDrive  with 960gb storage capacity, I could have an E5-1620 v2 with 128/256gb DDR3-1866 (24gb for OS, V.C.. etc, with remaining being a ram drive) system memory and still have some serious money left over. That's serious 'bang-for-the-buck". It's also not a good balance.

 

The idea behind this exercise is for me to put into prospective, file/hardware efficiency without necessarily "throwing" more hardware at it. A ram drive, even though read speeds can sustain 5k to 7k, is ALL consuming as pointed out in Tamper's #5 point. Plus, there is no caching when running an app in ram drive; you disable cache when doing so.

 

A ram drive system IS, hands down, the absolute fastest configuration It's the "cleanest" in terms of what is actually running, but not in terms of what is needed to get there or to get it started. It is, however, not the best or most efficient method of running an application in whole. That's why I'm enamored with it. And yes, I know what the performance gains are using a ram drive, having been using virtual system drives for several years.

 

As for my last system build, I do know two things:

 

 1) It will be submerged;

 2) The cpu will also be chilled.

 

plug_nickel

 

ps...I absolutely love to tinker. Tinkering is much more cost effective and is the "best-bang-for-the-buck"

Edited September 18, 2013 by almccoyjr

[Tamper 9]

*heh* Submerged...God love ya.  And I'm crazy, right...?

 

I guess that'll about cover the heat problems, huh?

 

I suspected this was about the texture/loading-stuttering-max speed issue.  I am very glad to see this; right on the edge of my seat here, and I can't wait to see the outcome!

 

As my sig shows, I use a Revo drive, precisely because it addresses the real bottlenecks Erik cited above (the interface, even SATA 6Gbps), by putting a fast RAID array on the PCIe interface.  It was around $350, only 120G, but that's enough to load Windows and a game or two if you wanted...you're right, though, they are pricey for the space.  And they can be a pain to make the bootable system drive, due to limited OROM space, which seems to have been overcome with newer BIOS, but I don't boot to it, so I'm not sure.  I know before I went to the UEFI BIOS, I was unable to 'see' both my REVOdrive and the hardware LSI/3ware RAID controller I had.  I never thought it was too crazy, once you consider what some people spend on video cards, which won't do anything for the stuttering itself - I was simply after the fastest way (short of a RAMdisk *ahem*) to get data from storage, which nothing else (CPU, video card, etc) will do, regardless of cost.

 

*lol* This RAM disk discussion, and a motherboard that supports 64G, certainly has me thinking...(damn you, Al) :P

 

(FWIW I am right there with you...why'd you think I go by 'tamper'??)

[almccoyjr 7]

Yup...Submerged my first and only time some 12yrs ago; my AMD Thunderbird Slot 1 with a Goldfinger on it to boot! Benching mostly. My second and last will be more main stream and chilled.

 

Because of Prepar3D, I'm back looking at "ramdrive" vs. slice/dice (resecting) files that have the most impact on a sim and relocating them to either a dedicated track(s) on a separate drive or "dumping" them into a virtual system drive. I have some scenery installs of 130/150gb. A VRD or RD just doesn't make any sense when trying to dump the whole application, but the read speeds are absolutely intoxicating.

 

I say Virtual System Ramdisc (VRD) as opposed to RAMdrive. A VRD is not persistant, where as a RAMdrive is a dedicated drive with a dedicated portion of system memory. Both types of drives require a program to load an image. That program can load an image directly into the RAMdrive or it can allocate a portion of system ram as a drive and load. When finished, you can unload and all system memory is available. One of the keys is the type of drive program to run a VRD. I use PRIMO RamDisc. It also allows dynamic in app saves when dismounting. With W7 x64 ULT, vc ram 2gb and "misc" using 4gb, I can run a 4gb VRD.

 

The problem is just how much of a VRD is actually needed. This is where all applications fail. They're designed and coded to run from a single source. It's left up to us to explore different levels of efficiency. You have to dig out all the files and processes that impact the sim. That makes it difficult, tedious and time consuming. But what the hey....

 

Many have 12gb of ram and could run a VRD very easily. Mudwasp68 has 64gb and could dump OFF completely into a VRD. I'm surprised he hasn't done that.

 

Separating and hard linking files has their downside as well: patches, updates and add ons don't play well with sub-linked files/folders.

 

I'm also exploring file placement; putting texures/scenery, etc on drive (1) with the core sim on drive (2). It seems feeding in during a call would be better than trying to feed out after the initial call. Just a thought.

 

In the end,  I believe a small SSD for OS and core files, a Revodrive for dedicated scenery/texture, aircraft, AI, and say two WD Raptor 10K 1tb in raid for the sim's core engines would be a good "hardware ramdrive" or an HRD.

 

To tinker on.

 

plugging along_nickel

Edited September 18, 2013 by almccoyjr

[+Erik 1,731]

We did a lot of experimenting with PROPS which is a pylon racing program for FS that Russell Gilbert helped us create. I mention this because this is 15 guys all flying together, using internet connections, and other aircraft with their own textures (which speaks to the point about multiple aircraft being the cause of stuttering) but when you're racing in close proximity stuttering will kill you especially in the case of MSFS where DirectPlay guessed the location of aircraft when packets from other users weren't received or received out of order. Given that what you're testing isn't this scenario, but ... we found some noticeable improvements in stuttering when we reduced the poly count in the other aircraft (aka Ai aircraft), this specifically helped because of the compression, decompression that happens and whether the processes can be offloaded to another thread or VPU. What we found is that we wound up against a limitation that wasn't so much hardware but software. Sure having a nitrogen cooled processor helped and 3000 CUDA cores with 10GB of GDDR5 was great but when you're trying to run the game and do all the rendering on the same thread you end up with stuttering. I suppose to be more specific only certain things were offloaded to the VPU where the aircraft that had a model and textures wrapped to that model still all went through the game rendering handled by the CPU. Now when games become better at multi threading you can offload some of those expensive video requirements for processor cores and give you better performance for lower costs. I'll be interested to see what you come up with knowing that CFS3 and MSFS are similar in design, even though I believe CFS3 was directx8 based and MSFS directx9 based.

 

I'm starting to confuse myself remembering all that we went through. Good luck!