glider1

I found the same things as you but am surprised that the blurry bug exists with AM=14 HT off. P3D really needs to support AM officially. Even ASN HIFI encourage people to use AM. There are legitimate reasons why it can be important to get the sim jobs off the default LP's. HT on and either AM248 or AM252 with P3D high priority could be a good interim solution for the blurry bug, at least the sim is smoother and we might be able to improve the blurry problem which to me seems like a rendering bug in the threading right now. I will keep your tweak suggestions in mind, but if this is actually a bug, tweaking won't help much. Did you experiment with kicking the LP's while the sim is running, when the rendering jobs get stuck on 100%? Does the effect persist or is it only a temporary benefit? It is curious that there is no change in the sim performance once kicked, just less CPU usage and proper texture loading....for a while or permanently? I couldn't get my i6700k stable at 4.7HT until vcore=1.38v on a Gigabyte gaming board and h100i cooler. I also needed to make sure that load line calibration was set to high. I don't think there is much to gain in going any higher than 4.7, 200MHz won't do much. Also nothing significant to gain in OCing the memory beyond 3200 either. There were tests done to show that diminishing returns happen quickly beyond these limits.

Haven't tried HT off recently - can't comment. For me HT off is wasting some i6700k potential and I have lots of addons that need their own LP otherwise random stuttering drives me insane. EDIT: Better with HT and AM for me. Still trying to work out how to solve the texture loading issue theBoom. By 'kick' I mean that if the sim falls so far behind with texture loading, nothing saves it unless you flip the AM while it is running. Then I found that everything sorts itself out. Main thread is much less busy, texture threads don't max out, textures load well. Not sure how long the effect lasts though and what exactly causes it. It might be a problem that happens right at the start up of the sim when an AM is set. Safest bet is to avoid getting the sim into the situation where it is overloaded with texture jobs - not easy if coming into a major airport! Perhaps that is why more than 4 LP's are the way to go, as well as P3D on high priority, as well as more conservative settings as well as possible tweaks. So far, don't think there is much to gain from FFTF or the bandwidth tweaks. For me, it is much more important to have smooth framerates and worse texture loading than the converse.

Question boils down to whether you need addons and want to optimise to the nth degree. If not, don't bother with AM. If you do need addons and don't want HT, then it is simply AM14 but perhaps just go with default AM (but prepare youself for random stutters) If you do want HT on and you want addons, then it comes down to three choices either AM85, AM116 or AM experimentals AM85: good VAS, possibly interference with addons if not done right. possible issues with texture loading AM116: good VAS better for addons possible texture loading issues AM experimentals: AM184: possibly improved AM116 with even less interference on the sim main job AM248: possibly improved AM116 with worse VAS but better texture loading AM252: possibly improved AM248 with worse VAS again, better texture loading but slightly more potential for interference from other jobs AM244: equivalent to AM248 but possibly marginally worse because of remnant conflict with other system jobs so why? Recommend HT on with the i6700k. HT depends on CPU architecture, and i6700k is latest evolution architecture. I am personally trialing AM248 on the i6700k with HT on and addons. I don't have VAS issues, and like how it clears the main sim job from remnant system jobs that happen on the second core leaving a total of 3 LP's clear for addon's and other jobs. So it could be smoother and have better texture loading with five LP's. Also trialing running P3D on high priority to help still more with texture loading a little bit. The easiest of all if you don't want to make decisions or experiment but you do need addons, then turn HT off and either default AM (which is AM00=AMFF) or go with AM14. Otherwise, prepare to get into the big wide world of sim optimizing. Keep in mind that I personally think that P3D has a threading bug with HT on where it can sometimes get stuck on 100% LP usage but unable to deliver textures unless it is kicked.

AM = Affinity mask: used to allocate simulator to particular cores on the processor when you want to run the simulator at the same time as addons and get best performance TB = ? Texture Bandwidth? vsync = syncing the graphics output of simulator to the monitor to eliminate tearing NI = Nvidia Inspector: for doing customised changes to graphics processor settings HT = Hyper threading: used to optimise CPU performance FPS limiter = either internally or externally limiting how many video frames the simulator outputs to the graphics processor I could be wrong on some minor details

With blurries, we think in terms of ongoing maintainable processor throughput as it infills and backfills the terrain. With P3D, we no longer think in terms of frame rates, more about blurries which are the way of knowing that the system is overloaded. P3D has tried to make it so that we can complete a flight with less compromise on framerates and more compromise on terrain rendition (but not at the critical airport destination where the terrain needs to appear so that we can land). If there aren't enough processing resources, this is a better approach than compromising frames. It is all about throughput of processing. If you change the AF mid flight, I think you can temporary cause processing to complete throughput of rendition, but later it will fall behind again because the underlying cause is not addressed. Affinity mask is able to influence (but not control) the job-scheduling load outside of the simulator and that is why it is helpful when addons are running as well as the simulator.

To debug issues like this, divide it into a processing or installation problem. If you pause or put the plane into slew, does the terrain draw properly after a wait? If so, it is a processing overload when the simulator is fulling processing. If the scenery never redraws properly, does it redraw properly after a reload? If it never draws properly at all, it is in an installation issue.

Badly chosen affinity mask can mean that the background terrain redraw processes don't get enough processing time. You only need it if you have add ons that competing with the sim for processing time. Without addon's, the P3D main process will be getting top jobscheduler priority in most cases regardless of AM, but then it becomes a question of turning down settings or minimizing complex scenery addons that swamp the background renderer.

As a quick test while you are flying, you could try increasing the priority of the P3D application to high or real and see whether you notice textures loading (back filling) a *bit* faster. There is no silver bullet, just a finely nuanced balancing act. It can mean the difference between textures that never load at all because the threads never gets processing time, or textures that load slowly, but at least fast enough relative to your other processing priorities. I did that yesterday with my i6700k 4.7OC. High priority backfills the textures a little bit quicker, "real" a bit quicker again (but still only a bit quicker not miles quicker). Problem with real is that other threads don't get a chance to complete and you start to get more stutters. The trick is that P3D and your addons both need to be fed processing time so that none of the threads are in waiting. That is how the simulation becomes smooth. If any thread is in waiting be it P3D or addon, issues start creeping in. You need to balance the entirety of P3D processing with your addons.

Wonder if anyone can explain the situation I am having. On Nvidia's latest drivers even up to 361.91, I needed to lock the frames at 32FPS or 33FPS to reduce any remaining slide-show effect on the rotating terrain while banking the aircraft. There was enough FPS head room so no problem. But without changing a single setting including VSYNC or TB=On, reverting back to 353.30 meant that I could lock it at 30FPS to achieve the same smoothness as was formerly possible only by adding a couple of frames to the lock. I'm on an old GTX760OC card.

It really depends on the hardware you have. I have an old GTX760OC. I started out with the latest drivers, felt unhappy about stuttering despite turning down settings. Then went back to 361.91 but still somewhat unhappy. Then dropped back to 361.43 but still unhappy. I've now dropped down all the way back to the one of the first drivers that came out for W10 which were 353.30. Although some "features" don't work, like being able to customize monitor refresh rate, I'm fairly sure there is an improvement in stuttering reduction (but have not quantified it). In cloud performance has also improved for a reason I don't understand. Could it be placebo? I doubt it but it is possible.

Glad you sorted it. Is Voiceattack how you get voice activated ATC without buying VOX ATC?

I'll answer my own question then by refering to the latest FSUIPC build notes: 69. The FSUIPC facilities for running programs at start up has been extended in two ways: · The number of both “RunN=” and “RunIfN=” parameters have both been extended from 8 to 16. · A processor code affinity mask can be specified for each, individually, with an extra parameter in the form AM=n with n in decimal or AM=Xn with n in hexadecimal. So it looks to me as if FSUIPC can only change the affinity of external apps, not DLL's that are loaded by DLL.xml. Question to anyone that understands this. If a DLL is loaded via DLL.xml, does that mean that its processing competes with the simulator for the same LP's, or does the operating system move the processing automatically to lesson the load on the simulator? I can understand that external apps can be manually tweaked by affinity, but not understanding internal DLL's operation on the loading down of the simulator.

Does the new FSUIPC allow us move DLL addon processing away from the LP's that the sim uses? I didn't think we had any options on that (only for external exe addons). Would be nice.

to make it worse there are two split camps in the P3D 3.2 club, those on original and those on 3.2.3 which both need different variables files for world camera. Question is whether there is something in P3D that prevents the EZDOK designer from making it it version independent, or whether the designer actually wants this ?feature? in his software?

Your CPU is a I5-4670K isn't , is that significant? Have you OC'd it? Would it make any difference?

So with even with ATW, the simulator needs to be running at 80fps minimum in order for us to even consider plugging in a rift? Is that it? Thanks for the videos appreciate the effort. So that means you must have been getting at least 80fps with all your addons before you plugged in the Rift?

What FPS minimum do we need to be able to maintain in P3D without Rift, in order to know that a Rift would work stutter free? What would be the test setup for that so that we could test our systems before buying a Rift?

I'm running W10 but I only did it because of a new machine. It's fine but I doubt there is any point to upgrade (there is no performance improvements that I have heard of) unless you either are changing the hardware out or there is some software that runs best on W10 like a future hypothetical DX12 simulation which doesn't exist yet. You might also want to do it for other reasons that you use your PC for.

I disagree that it is human nature. If that were true, then we would all not accept that the lights in our house are working to provide light - we would deliberately smash them so as to put new light globes in? No, it is because of expectation. We push the simulator to the limits because we expect more performance than we are getting for nothing, because we think that the performance we want is the performance that everyone else is already getting (the pilots we never meet). EDIT: or the performance we believe "ought to be justified".

To be more fair to the frustration of simming, the line between software and hardware is blurry. We often don't know whether it is hardware problem, or some kind of software problem that is not really our fault. You have to define what balance is and what the line between hardware and software is. I suggest that the "truth" be re-written as: ....but the key to successfully utilize 30Hz approach is to establish a personally acceptable level at which you are getting 30HZ most of the time, then once you have determined what the faults and limits of the underlying software are, then find a balance between YOUR hardware and the P3D settings to maintain 30 FPS.

ORBX is not designed for P3D at the engineering level, even it supports it at the marketing level. Think about the history of it. ORBX comes out of FSX that has fullscreen exclusive mode at 1/2 Vsync. ORBX adds scenery to it, keeping it smooth as possible within that mode. P3D cannot do that mode. P3D really needs special scenery written for it that will allow P3D to run at VSYNC not 1/2 VSYNC. You can get pretty close, but you have to widen your attitudes towards what you think is smooth. P3D runs brilliantly out of the box without ORBX, so there is a lot of work to do to get it to work for something it was not designed for. I have found that getting the affinity mask sorted, being conservative with the settings, and going down the path of locking frames with Nvidia inspector (see other thread) to be pretty good. I bet though - down the track I will hit the same problems again because the fix is only relative, not absolute. EDIT: I don't want to go down on P3D. The 3.2 update for me has been the best yet and performance has improved.

It would be amazing to offer it as an option. I would personally love it. I doubt they will do it because fullscreen exclusive introduces more system dependent issues that they would then have to support (which costs money) as well as other issues like support for multiscreen monitors lah de-dah. If you look at the smoothness of it in FSX, it is the best so long as the underlying minimum framerate is significantly in excess of the locked framerate. P3D can get fairly close but only if you throw a lot more hardware at it. In any case, all this is old technology because with the coming of VR, there are new technologies that will control smoothness - but you will have to throw more new hardware at that too!

Question about this NI locking concept. Is this the sequence of events? Assume that locking to VSYNC at a multiple of 1:1 is not possible because we can't get the frame-rate high enough. So: - P3D delivers frames as fast as it can to the GPU on unlimited - GPU is forced to restrict delivering frames to the monitor by the NI frame limit - We try to match NI with multiples of the monitor HZ as best we can. Conclusions that I reach from this: NI frame-limit is quite imprecise Monitor HZ is also not perfectly precise (can be tweaked with custom resolutions) NI and HZ are NOT linked and so we are tuning the two like a tuning fork on a guitar string to try and tune out any non-smooth depiction and reduce NI-HZ to zero difference (but it will probably drift). Flying in a straight line it can look smooth, but the tighter the bank, the more the terrain panning jerkiness is modulated by a beat frequency which is NI-HZ (whatever the difference is) There is absolutely no way to fix conclusion (3) above even with expensive hardware. You could throw the next gen PASCAL card at this and the smoothness issues would still occur BUT - expect smoothness to improve with higher frame-rates not because of the frame-rate itself but because the difference between NI and HZ decreases in relative terms as the frame-rate increases. Are these conclusions sound? If so, my ultimate conclusion is that NI frame limit of 30 is no man's land because the frame rate is not really high enough to mask the problem of conclusion(3) above, and GSYNC doesn't work at NI30 either. From my own experience, smoothness really starts to improve at NI40, but this is unsustainable unless you are on default scenery -but if it were - you wouldn't even need this NI fix proposed by SteveW because then you could use GSYNC (if you had it).

Do you think you will preference 30Hz capable panels?

Best of luck with that - you have a dream setup - a 30Hz monitor so that P3D can lock to VSYNC! The situation you seem to be in is unusual. The simulator is delivering absolutely smooth frames for terrain movement, but view movement now stutters. They are two different things. There doesn't seem to be any logical reason why view changing should be an issue for you other than some stupid glitch in the drivers or background scheduling somehow. Hmmmm...... EDIT: try running at a lower resolution just to cut out any possibility of GPU issues.