Jump to content

Cruachan

Members
  • Content Count

    3,568
  • Donations

    $75.00 
  • Joined

  • Last visited

Community Reputation

705 Excellent

5 Followers

About Cruachan

Profile Information

  • Gender
    Male
  • Location
    Midlothian, Scotland
  • Interests
    Electric Guitar, Photography, Flight Simulation, Astronomy and Gardening (as wife requests)

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

About Me

  • About Me
    Retired Medical Practitioner

Recent Profile Visitors

8,290 profile views
  1. Hi Ray, Perhaps I misunderstood, but I was under the impression all was well while using SSNG whereas you were experiencing strange behaviours with various addons when SSNG was not part of the equation. I was simply wondering whether SSNG was creating unique configurations as part of its method of operation. If these configurations remained in place when P3D was run directly from its desktop icon then perhaps this might explain those anomalies. Uninstalling SSNG should, and again I say hopefully, undo those modifications, if such exist, and would be a way of confirming that SSNG was somehow involved. Regards, Mike
  2. Hi Ray, Dare I suggest you try the effect of uninstalling SSNG temporarily? If SSNG is in some way responsible - does seem likely since everything works when SSNG is in play at the start - then uninstalling should (hopefully) reverse any changes implemented by SSNG and the anomalies, as experienced when P3D is run from the desktop shortcut, will be gone. In theory this should not involve any risk of breaking the sim, but then again Sod’s law might intervene to determine the outcome. Maybe consider backing up the SSNG installation and your User folder before delving deeper into this. Regards, Mike
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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!
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...