Cruachan

Hi, Sorted! Turns out I must have been clicking on the blue text instead of the active box above the text. Thanks everyone for your helpful guidance. No excuses, I need to try harder in future ☹️ Regards, Mike

Hi, Pretty sure I tried that and, for whatever reason, each option was unresponsive when clicked. Consequently, my assumption was that these details would be requested later as part of the purchase process. I’ll give them another go tomorrow and report back. Certainly makes sense. Fingers crossed! Thanks! Regards, Mike

Hi, Trying to purchase RealityXP Garmin GTN 750 for P3D V5.3 HF2 but am prevented from so doing as the Secure Purchase option is greyed out!? As you can see, the application of the coupon worked. My intention is to purchase the RXP GTN 650 as well. I have yet to try its E-Commerce installer (rxpGTN-650-FSIM.exe). Seems little point until this is sorted out. This is my first purchase of these products from Reality XP and the intention is to replace the Flight1 GTN Complete Edition (GTN 750 and 650) installation which, apparently, now lacks ongoing support. The Garmin Aviation Trainer Launcher has been updated to v3.2.3.0 Any help would be appreciated. Thanks. Mike

Hi @MammyJammy, I’m afraid you don’t know me very well 😀 Steve, on the other hand.... really don’t know where he gets his patience when it comes to helping ageing idiots like me. Some would say that I’m my own worst enemy when it comes to obsessing over how things work. Yes, I could take the easy way out, but where’s the satisfaction..lol! BTW, I have been using your tool, including the presets, to help towards my understanding of the various outcomes. Thank you, the excellent design of the interface makes these calculations a doddle for the user who is motivated to experiment. Regards, Mike

Hi Steve, Really thought I had a handle on this, but the above appears to be at variance with my earlier conclusions: 07,06,05,04,03,02,01,00=core number 00,11,11,11,01,01,01,11=P3DCoreAffinityMask=1621500,00,00,00,00,00,01,00=MainThreadScheduler=2 = LP200,00,00,00,00,01,00,00=RenderThreadScheduler=3 = LP400,00,00,00,01,00,00,00=FrameWorkerThreadScheduler=4 = LP6 I wrote: “Is it as simple as counting from Core 00=1, Core 01=2, Core 02=3 and Core 03=4 and the threads are placed on the Logical Processor of each of the three Cores as defined by the P3DCoreAffinityMask?” MainThreadScheduler = 0 RenderThreadScheduler = 1 FrameWorkerThreadScheduler = 2 In your example with the 0, 1 and 2 ThreadScheduler Physical Core assignments, these are matching the core numbers as defined in your first line, i.e. Core 00 = 0. However, the ThreadScheduler Physical Core assignments in my example appear to be suggesting that Core 00 is in fact being designated as 1. You liked that post so my assumption was that this was correct. Now it seems that I was mistaken 😟 Hence my relapsing state of confusion...lol! I’m afraid this numpty still needs your ever helpful hand to bring some further clarity, please. Thanks. Regards, Mike

Hi Steve, Thank you! I cannot believe how often I read and re-read the above segment of my last post and yet still managed to miss a fundamental error! It should, of course, have read: “Is it as simple as counting from Core 00=1, Core 01=2, Core 02=3 and Core 03=4 and the threads are placed on the Logical Processor of each of the three Cores as defined by the P3DCoreAffinityMask?” 07,06,05,04,03,02,01,00=core number 00,11,11,11,01,01,01,11=P3DCoreAffinityMask=1621500,00,00,00,00,00,01,00=MainThreadScheduler=2 = LP200,00,00,00,00,01,00,00=RenderThreadScheduler=3 = LP400,00,00,00,01,00,00,00=FrameWorkerThreadScheduler=4 = LP6 So, I think I’ve understood how this works correctly...just didn’t express it with sufficient care and attention ☹️ Best regards, Mike

Thanks Steve, I’ll certainly give 16215 a shot. Will need to keep an eye on the max temps reached by Core 0 assuming, that is, P3D makes use of LP1 in addition to ‘maxing’ out LP0. I am assuming that main thread activity will not be shared by the 2 LPs...or am I wrong about that? EDIT: Actually I am wrong about that as, somewhat belatedly, I note that you have moved the three ThreadSchedulers: 00,00,00,00,00,00,01,00=MainThreadScheduler=200,00,00,00,00,01,00,00=RenderThreadScheduler=300,00,00,00,01,00,00,00=FrameWorkerThreadScheduler=4 I’m confused! So, what’s new?...lol. Could I ask you to run over again how you arrive at 2,3 and 4 for the three ThreadSchedulers in the above example, please. Is it as simple as counting from Core 0=1, Core 2=2, Core 3=3 and Core 4=4 and the threads are placed on the Logical Processor of each of the three Cores as defined by the P3DCoreAffinityMask? Just fired up Prepar3D and I note that the main thread is now running on LP2 and... surprise, surprise...while sitting on the rwy at 1S2, logical processor activity is holding at 80%. This looks promising! Other activity is seen on LP4 (20%) and LP6 (10%). LP0 (10%), LP8 (10%), LP14 (10%) Regards, Mike

Interesting! Looks like the rules are changing! Are you now suggesting we try the effect of masking the first 2 LPs on Core 00 for P3D whereas before it was only LP0. It does seem logical as LP1 usually sees very little activity. Mike

Hi Steve, To be honest, it was only a relatively brief test session following an extended break from swimming. I was running an earlier untested driver set (472.12) which quickly produced the ‘Device Hung’ error (despite Ray’s helpful advice regarding the registry entries) and, following a restart, subsequently crashed my PC - PC rebooted spontaneously while P3D was running - at first I thought we had experienced a power cut, but this proved not to be the case. My favoured test area is at ORBX’s Darrington Mun., WA. During the test the sim ran very smoothly with only one brief hesitation and frame rates were maintained at around 30 throughout. Core 0 was saturated throughout. Since then I have updated to the latest drivers (511.23) which seem solid enough following an extended period of testing (including 3DMark). These are the JobScheduler entries I’ve used so far with V5.3 HF2: [JobScheduler] ;AffinityMask=64853 ;AffinityMask=21845 AffinityMask=65535 ;P3DCoreAffinityMask=64853 ;P3DCoreAffinityMask=21845 P3DCoreAffinityMask=21844 MainThreadScheduler=0 RenderThreadScheduler=1 FrameWorkerThreadScheduler=2 Probably makes little difference, but I was modifying my previous post around the time you posted. Regards, Mike P.S. Sorry about the double spacing/enlarged font above - that’s what happens when you try to shortcut your effort by copying original text from a .cfg file, emailing said text and then copying/pasting into a forum post!

Referencing Add-ons started by P3D and not the user. Would that go some way towards explaining my observation in an earlier post in this thread that Core 0 (HT=ON) activity saturated persistently at 100% while P3D was running and yet this was not the case while using an AffinityMask that placed P3D’s main thread on Core 2 of my i7-5960X instead of on Core 0? Something along the lines of: [JobScheduler] AffinityMask=65535 (or 21844?) P3DCoreAffinityMask=21844 MainThreadScheduler=0 RenderThreadScheduler=1 FrameWorkerThreadScheduler=2 Mike

Hi Steve, So, keeping P3D away entirely from core zero, which is favoured by the Windows O/S, would seem to be a good idea? The down side is that it reduces the core count available for rendering based operations and/or running Addons. However, in multi-cored CPUs (8+) with HT=ON, unused LPs on those rendering cores could be brought into play by adjusting the Affinity Mask to compensate for this deficit. Regards, Mike

Hi Steve, I wonder whether some of the confusion arises from stating ‘Addons are launched by the sim’ which might imply that such Addons are being called by P3D. Consequently such Addons might be being considered as having the right to use any of the same LPs hidden by the mask and intended to be reserved for P3D which, of course, is not the intention. Strictly speaking, Addons are not actually launched by the sim. Instead each is launched outside the running sim by the user or via a 3rd Party facilitator like SimStarter or FSUIPC in a predefined order. They will then link/connect to the sim while running on any available unmasked core or LP/LPs, as determined by the Windows Job Scheduler which is not ideal or, preferably, will occupy only those specific cores/LPs as assigned by a bitmask described in a bat file or, more easily in my case, via the GUI of Process Lasso. These latter solutions should ensure that any Addon is prevented from running on physical cores 0, 1 and 2. Currently, I’m experimenting by keeping everything P3D related away from core 0 (LPs 0 and 1 with HT=ON). Leave that core for Windows related tasks. Early results are suggesting that this is having the desired effect by preventing the P3D main thread on LP2 from saturating at 100%. This was not achievable on my somewhat conservative setup while the main thread was running on LP0 which meant I had little or no spare overhead available. Best regards, Mike

Trying my best to untangle the intentions behind the new JobScheduler scheme and that, for me, might well have been the light bulb moment! I did not understand why in some posts and, indeed, under JobScheduler in Prepar3D.cfg (after first run of P3D) we were seeing the same initial values for AffinityMask and P3DCoreAffinityMask. In other posts the AffinityMask decimal value would also be CPU specific reflecting the total count of logical processors (available for P3D and 3rd Party Addons) for that CPU (with HT enabled), whereas the P3DCoreAffinityMask value would, instead, define only those LP’s masked for exclusive use by P3D. In CPU’s with lower core counts, the identification and selection of specific cores for sharing with or the exclusive use of 3rd Party Addons becomes ever more important. So, it makes sense, I think, to match the ‘global’ AffinityMask with the user-defined, P3D specific P3DCoreAffinityMask and, by so doing, any remaining unmasked LP’s can be selected appropriately in, say, Process Lasso for running 3rd Party Addons...much as we were doing hitherto in previous versions. Mike

Hi @mobiel Is it just me or do I risk spoiling your day? Prepar3D is 64bit these days so should be installed under Program Files and not Program Files (x86)...assuming that was your intention. The default path would have been the former. Perhaps it’s not so important for a virgin installation but once you start installing Addons it might lead to issues. Perhaps others could comment about this. Regards, Mike

63 (Dec) = 111111 (Bin) If this is LM’s default value for what I’m assuming to be a 6 cored CPU then the initial value is being based simply on the physical core count of the CPU with HT=OFF. This is unlikely to be ideal. With version 5.3 I believe that, by giving us these additional options, LM are encouraging us to take control of optimisations to satisfy our individual, often unique, requirements. By now, LM will be aware that we are becoming much more Affinity Mask savvy these days and, I’m deducing, felt the time was right to help us to exploit this hard won knowledge by expanding the Affinity Mask possibilities. Mike