AM=15. What does that refer to?Stephen, have you played with BP of 1 or 2MB? I am finding this is actually superior in that cockpit textures load instantaneously even in birds like the PMDG 747, so overall it's a little better than BP=0 I think. And this is supported by DPC latency check too, just a little though. What has shocked me is how BP in the higher ranges of 5 to 10mb or more actually is a bad thing on this machine. I was running at 5mb for many months.Noel

Hi Noel,Yes I did but found that the BF=0 shoved my performance over an edge so to speak. The difference is quite fascinating actually, not that my system was a slug in any case, being not a whole lot different from your own. Yours must be faster though. I made my FSX backwards compatible to Vista 64 which eliminated the occassional black squares that looked a lot like near video starvation. I am sure happy with how FSX, at least this advanced modified version of it, works above my expectations and just keeps getting better and better. Can't wait to fly my L-39 over FTX's PNW!

Hi Noel,Yes I did but found that the BF=0 shoved my performance over an edge so to speak. The difference is quite fascinating actually, not that my system was a slug in any case, being not a whole lot different from your own. Yours must be faster though. I made my FSX backwards compatible to Vista 64 which eliminated the occassional black squares that looked a lot like near video starvation. I am sure happy with how FSX, at least this advanced modified version of it, works above my expectations and just keeps getting better and better. Can't wait to fly my L-39 over FTX's PNW!

I can agree with that I am so pleased with how the sim is running for me. Getting away from the higher BP setting added some icing on an already nice cake and now it's really only held back by raw horsepower. I can run this machine at 4.1 or 4.2Ghz, but this takes a significant increase in core voltage (to 1.4125), tho under the absolute maximum (1.45v) and so it's just not worth it for the measely reward you get over my default speed of 3.88Ghz. This processor runs stable at 1.3625v at 3.88Ghz, so that's where it sits for now. I ran it at 4.1Ghz or above for the past year, but decided I was happy enough with this cpu to not risk damaging it (too soon!). I may already have done that I don't know. Yes, bring on the PNW. I will be first in line on that piece. I am making friends with the PMDG J41, though it's been a bit of a struggle, impatient person than I can be.

After upgrading my system (see profil) i don't have any DPC Latency/sound issues anymore, no matter what BP value i choose.

I can agree with that I am so pleased with how the sim is running for me. Getting away from the higher BP setting added some icing on an already nice cake and now it's really only held back by raw horsepower. I can run this machine at 4.1 or 4.2Ghz, but this takes a significant increase in core voltage (to 1.4125), tho under the absolute maximum (1.45v) and so it's just not worth it for the measely reward you get over my default speed of 3.88Ghz. This processor runs stable at 1.3625v at 3.88Ghz, so that's where it sits for now. I ran it at 4.1Ghz or above for the past year, but decided I was happy enough with this cpu to not risk damaging it (too soon!). I may already have done that I don't know. Yes, bring on the PNW. I will be first in line on that piece. I am making friends with the PMDG J41, though it's been a bit of a struggle, impatient person than I can be.

I might be missing something but my rig rocks at 4.2ghz. So so at 4ghz. There is a direct correlation between blurry elimination and core clock. Of course I'm a free-form experimenter (the most dangerous kind) so I can't document squat.jja

I might be missing something but my rig rocks at 4.2ghz. So so at 4ghz. There is a direct correlation between blurry elimination and core clock. Of course I'm a free-form experimenter (the most dangerous kind) so I can't document squat.jja

Hi jja,I agree but only up to a point.Even IF the CPU clock was 100% directly responsible for FSX FPS or insert performance gains for drawing the terain and keeping it sharp (which it isn't) If you just do the math we are talking 1.+ FPS increase and in real world results it is even less.4000 + 5% = 4200 at 30 FPS + 5% = 31.5 (again >IF< CPU was 100% responsible for FPS) or again calculation/rendering performance gain is 5%I'm not knocking a good overclock as long as you know what you're doing and have good cooling, great! Just trying to avoid people from frying their CPU's just to gain a fraction of performance, not to mention the weird throttling if not properly cooled that will actually stunt your performance not increase it.However on the other hand the smell of a well cooked CPU is something I am rather fond of... :(

Hi jja,I agree but only up to a point.Even IF the CPU clock was 100% directly responsible for FSX FPS or insert performance gains for drawing the terain and keeping it sharp (which it isn't) If you just do the math we are talking 1.+ FPS increase and in real world results it is even less.4000 + 5% = 4200 at 30 FPS + 5% = 31.5 (again >IF< CPU was 100% responsible for FPS) or again calculation/rendering performance gain is 5%I'm not knocking a good overclock as long as you know what you're doing and have good cooling, great! Just trying to avoid people from frying their CPU's just to gain a fraction of performance, not to mention the weird throttling if not properly cooled that will actually stunt your performance not increase it.

No arguments - I try to think about the bigger picture and include the OS / Hardware platform (that drives FSX) in my thought process. I have an SSD and it takes 2 seconds to shut down Win 7. Crazy.

No arguments - I try to think about the bigger picture and include the OS / Hardware platform (that drives FSX) in my thought process. I have an SSD and it takes 2 seconds to shut down Win 7. Crazy.

Right, we not only have the OS/Driver to hardware relationship and game programing but just in hardware alone we have CPU>Memory>memory-sub-systems>GPU>and Audio>controllers> = perfomance results.2 seconds? HC!

I might be missing something but my rig rocks at 4.2ghz. So so at 4ghz. There is a direct correlation between blurry elimination and core clock. Of course I'm a free-form experimenter (the most dangerous kind) so I can't document squat.jja

I'd like to see hard proof on that one, which is difficult to obtain. You are looking at a grand total of 5% difference on those two core clock speeds, which is in the realm of insignificant in all other applications. I'd bet money you are getting 3-4% improvement in everything related to core clock, if that. I don't see much difference between 4.2 and 3.9, or let's put it this way, I see (all things "seen" in FSX are up for debate until true controlled comparisons are made) the predicted small difference in outcome. There is nothing objective I can think of that would explain going from so so to rocks with a 5% change in thruput. Let's say we set up the most controlled experiment possible. Save a flight, use that exact one set up a specific runway and time of day. Save the flight and don't keep any weather generators active, etc.Now try to quantify what seems to matter to people: frame rate (that's easy), smoothness (that is typically subjective and unquantified, but I think could be), and now image quality (mostly subjective once again).Frame rate alone, in my estimation, will improve by maybe 3-4% with a 5% increase in core clock, which is not significant. Try to come up with a way to quantify smoothness: maybe count the number of perceived stutters/hesitations per the first 60 seconds of a specific flight with the autopilot was engaged at exactly the same point etc; ANY deviation from absolute perfection counts 1. How to quantify texture update rate and IQ is really a challenge. All of this just points to the very subjective nature of estimating the effects of something like dialing up the core clock 5%.There is also the bias of the observer. 4.2Ghz sounds like it ought to rock for sure. Until it's objectified if that's a word, it's all a bit iffy to me. What really strikes me is how one can go up and have a super liquid smooth flight in complex terminals one day, and have it sit tight at 30 frames in a 3rd party bird on taxi, then the next day go out again at the same terminal, and find your frame rate sunk down to 23. This happens in FSX and points to the critical importance of setting up truly controlled experiments. We do need a way to rate smoothness and image quality so that they can become part of the performance rating in question. I do stay with my current opinion that dialing down the BP setting has helped signficantly in term of total smoothness, and this is consistent with DPC latency testing which has improved since discoving the value of the lower BP setting on this machine.Not trying to spark a debate, just expressing how I see the issue.Noel

You are looking at a grand total of 5% difference on those two core clock speeds, which is in the realm of insignificant in all other applications. I'd bet money you are getting 3-4% improvement in everything related to core clock, if that. I don't see much difference between 4.2 and 3.9... Frame rate alone, in my estimation, will improve by maybe 3-4% with a 5% increase in core clock, which is not significant.

I don't normally chip in on these sorts of discussion, as they don't really get anywhere. But I'd like to point out one little flaw in this part of the argument:Bottlenecks.If you have a water pipe which can carry just enough water for your demands, but then make it a tiny bit smaller, what happens? A severe drop in water rate, not to mention juddering noisy pipework! Same with motorways / freeways / autobahns -- if it can just cope with the volume of traffic then things flow well. Once there's just a little too much? Traffic jams, queuing, etc. It's the nature of flows, flows of anything -- water, traffic ... and bits of data.So, with computers it's the same. Data flow. If the bottleneck is the CPU speed then a small increase can make a dramatic improvement, much more than mere CPU speed difference would indicate. If the main bottleneck is elsewhere, then it won't. In my case, my previous PC was water-cooled and overclocked to 4 GHz, but the problem turned out to be the memory -- the 800 MHz speed wasn't enough. And the damned mobo (an Intel Skulltrail would you believe?) wouldn't drive anything faster!My current system is also water cooled and overclocked to 4.5 GHz, and it took DDR3 triple matched 2000 MHz memory to make full use of that speed!So, look to what is throttling things: the bottleneck. Solve that first. It'll be memory or processor most often, but a small change in whichever it is, it can certainly give a surprisingly large jump in results.Okay. That's my say. Carry on now ... <G>RegardsPete

Excellent post Pete

Thanks SpiritFlyer. That was a really nice thing to say! It is a great pleasure and frankly, an honour to "re-join" the flightsim community. And FSX is looking very promising right now! Here is that performance rating path in Win7 for those of you who may want to try it. The screenshot is below and it is the top-most option which does this detailed re-rating. I did not try FSX before this performance rating, though, but based on what I've read in several threads, I don't believe that would have made a big difference in the stutters.By the way, I DID also install the latest NVidia graphics drivers - 196.21 but these were already installed last night when I had the stutters, so this is just an FYI ...If anyone has any questions at all, to clarify anything or for more detail, please do not hesitate to ask me.John

I thought I had posted the screenshot of how to get the performance re-assessment but it is not there. Here is the navigation path for those of you who may not know how to get to it in Windows 7 Pro 64-bit (probably the same in all version of Windows 7, Home Premium or higher):START - CONTROL PANEL (organize control panel by "icons" rather than by category view) - PERFORMANCE INFORMATION AND TOOLS - ADVANCED TOOLS - CLEAR ALL WINDOWS EXPERIENCE INDEX AND RE-RATE THE SYSTEM...However, I have returned, for now anyways, to Windows XP. Too many issues which I find are hit and miss with no real solutions in sight, with Win7.My flight from yesterday was pretty great in WinXP Pro 32-bit: From Los Angeles LAX to Miami International, with the 747-400 default, using default scenery, no addons yet. Frame rates were high teens to low 20's taxiing and 40's to 60's in the air or even higher. I had high quality displa settings but not the highest, since I am pretty sure my graphics card can't handle it. I will do some more flights next week and continue testing. But it is much smoother in XP, with hardly any micro stutters (very rare micro) and NO big stutters at all.

I don't normally chip in on these sorts of discussion, as they don't really get anywhere. But I'd like to point out one little flaw in this part of the argument:Bottlenecks.If you have a water pipe which can carry just enough water for your demands, but then make it a tiny bit smaller, what happens? A severe drop in water rate, not to mention juddering noisy pipework! Same with motorways / freeways / autobahns -- if it can just cope with the volume of traffic then things flow well. Once there's just a little too much? Traffic jams, queuing, etc. It's the nature of flows, flows of anything -- water, traffic ... and bits of data.So, with computers it's the same. Data flow. If the bottleneck is the CPU speed then a small increase can make a dramatic improvement, much more than mere CPU speed difference would indicate. If the main bottleneck is elsewhere, then it won't. In my case, my previous PC was water-cooled and overclocked to 4 GHz, but the problem turned out to be the memory -- the 800 MHz speed wasn't enough. And the damned mobo (an Intel Skulltrail would you believe?) wouldn't drive anything faster!My current system is also water cooled and overclocked to 4.5 GHz, and it took DDR3 triple matched 2000 MHz memory to make full use of that speed!So, look to what is throttling things: the bottleneck. Solve that first. It'll be memory or processor most often, but a small change in whichever it is, it can certainly give a surprisingly large jump in results.Okay. That's my say. Carry on now ... <G>RegardsPete

Correct, and what if you totally do away with a slow component like the NorthBridge on my ASRock P55 Extreme that no longer has one?What a fun architecture.jja

I don't normally chip in on these sorts of discussion, as they don't really get anywhere. But I'd like to point out one little flaw in this part of the argument:Bottlenecks.If you have a water pipe which can carry just enough water for your demands, but then make it a tiny bit smaller, what happens? A severe drop in water rate, not to mention juddering noisy pipework! Same with motorways / freeways / autobahns -- if it can just cope with the volume of traffic then things flow well. Once there's just a little too much? Traffic jams, queuing, etc. It's the nature of flows, flows of anything -- water, traffic ... and bits of data.So, with computers it's the same. Data flow. If the bottleneck is the CPU speed then a small increase can make a dramatic improvement, much more than mere CPU speed difference would indicate. If the main bottleneck is elsewhere, then it won't. In my case, my previous PC was water-cooled and overclocked to 4 GHz, but the problem turned out to be the memory -- the 800 MHz speed wasn't enough. And the damned mobo (an Intel Skulltrail would you believe?) wouldn't drive anything faster!My current system is also water cooled and overclocked to 4.5 GHz, and it took DDR3 triple matched 2000 MHz memory to make full use of that speed!So, look to what is throttling things: the bottleneck. Solve that first. It'll be memory or processor most often, but a small change in whichever it is, it can certainly give a surprisingly large jump in results.Okay. That's my say. Carry on now ... <G>RegardsPete

How does the water pipe analogy hold up in this argument Pete?Let's say you have well matched components in the plumbing system or other particle flow system in the physical realm. The pump that feeds the pipe puts out 1 liter per minute maximum output to the outflow pipe, which is 10 feet long and sustains a certain static pressure per lineal foot of pipe. At 10 feet, this pipe can accomodate exactly 1 liter per minute maximal terminal flow rate. All's well, there are no bottlenecks. Now increase the pump output rate. What happens? Perhaps a little more static pressure, and the net gain is nil or less than nil due to backpressure for the pipe's terminal outflow rate. Or the pump burns out as can happen in ventilation systems.If you add a timing element to this it could change the outcome I can see, but I'm not sure how proportional and linear that relationship would be in the data moving realm. If there is mismatched timing involved, then one might stumble into a superior rate, but this won't necessarily be secondary to the higher pump rate, it will be secondary to improvements in timing efficiencies between key components. Didn't you say it yourself, your system has really benefited from a bigger outflow pipe? Look at your maximum theoretical bandwidth going from 800mHz memory and a northbridge, to 2000Mhz and an onboard memory controller. If you take your current rig, throttle it back to 4.25 Ghz with your same 2000Mz ram, then move it back up to 4.5Ghz, I'm guessing you will not be experiencing >5% improvement in total performance. I think we are agreement that it is critical to solve the bottlenecks first, but I'm still not to sure how you go from so so to rocks with a 5% increase in pump output.

Excellent post Pete

Nick or whomever,Tell me what I am seeing here if you kindly would.To get my QX to run stable at 4.1Ghz, I need a BIOS core voltage setting of 1.40v When I do this Everest or CPUID sensors show a core voltage of 1.36 idle, 1.31 at peak load. At 3.88Gz, I need a BIOS setting of 1.3625v, and show 1.31 at idle, and 1.27v at peak load via the sensors. The datasheet states the VID range for my QX is 0.85 - 1.3625v. So, the question is, since the sensors are showing 1.36v/1.31v with a 4.1Ghz overclock, have I exceeded the processors VID range because I have core voltage at 1.40v in the BIOS, or am I still within spec since the sensors show voltages less than 1.3625v? Intel also describes an "absolute maximum core voltage with respect to Vss" as 1.45v. Noel

I think for simulation the pipe analogy does actually hold for processing too, because FS is needing to do things in real time. With a certain amount of data to process in a fixed time (because of the real time nature of simulation), the processor can be a bottleneck just as the memory and video access can be. You can reduce the amount of data (sliders to the left, simpler scenery), or you can increase the processor speed. When the speed is at least sufficient for the amount of data to be processed in time then you'll get smooth results (assuming of course no bottlenecks elsewhere). More speed will increase the frame rate proportionally but below the bottleneck speed you'll not have smooth flight without reducing the data to be processed. So that's a bottleneck for your desired simulation settings.It isn't the same for normal computational uses of computers, where a faster processor gives proportionally quicker results (assuming no hold ups elsewhere of course). The difference with simulation is that there's the real time element. The results need to be used in a fixed time or they aren't of much use!Note that I've always tended to judge FS performance by smoothness rather than by frame rates. Turn the frame rate display off. Increase the sliders and complexity. You've hit a bottleneck somewhere when it's no longer smooth.Pete