FS-PC Performance


Hello Captains,
Dit wordt een lang verhaal en voor sommigen waarschijnlijk niet erg spannend. Maar als je geïnteresseerd bent hoe de prestaties van je flightsim-pc worden beïnvloed, moet je dit lezen. Het kan zijn dat veel van de dingen die je dacht te begrijpen over prestaties, niet langer waar zijn. Tenminste, niet meer sinds we zijn overgestapt op het x64-platform van Prepar3D v4.

Voordat je verder leest, weet dan dat het niet de bedoeling is om een ​​technische discussie aan te gaan over hoe processors werken, hoe rendering-engines werken, of om de kern van de Prepar3D-engine te ontleden. Wij vereenvoudigen een paar zaken om het onderwerp voor iedereen begrijpelijk te houden en natuurlijk is niet alles hier een waarheid als een koe….

In plaats daarvan is dit een algemene illustratie van waar we zijn begonnen, hoe we hier zijn gekomen, wat we hebben en hoe dit je simprestaties dagelijks beïnvloedt. Op een aantal punten heeft deze discussie ten doel om een ​​aantal lang gevestigde misverstanden, (die hardnekkig herhaald worden door Simmers) te corrigeren. Hopelijk leer je met deze wetenschap hoe zaken te evalueren en leer je waardoor je sim minder goed of slecht presteert dan je verwacht.

De afgelopen jaren heb je op onze website al diverse publicaties kunnen lezen over performance van de pc’s tijdens het FSX-tijdperk. Ook deze publicaties hadden ten doel om je bewust te maken van de beperkingen van zowel de flightsim software als ook het (toen nog 32-bits) operating system.
We zetten ze nog even op een rij … en misschien is het leuk dat je nog eens terugblikt.
Wij publiceerden eerder in:
Januari 2010:            game-performance-is-slower-than-expected
flight-simulator-x-game-performance-is-slower-than-expected
Januari 2011:             affinity-what-it-is-and-how-to-configure
Februari 2012:          tweaking-fsx-cfg
Maart 2014:               the-sense-and-nonsense-of-fps

Recentelijk werd de PMDG737NGXu geïntroduceerd en naar aanleiding daarvan schreef Robert R. Randazzo van PMDG weer eens in zijn gebruikelijke klare taal hoe het heden ten dage zit met de invloeden op de performance van onze flightsim-pc.

Wij vonden het de moete waard om deze – toch wel droge -“tech-talk”- te vertalen` en hier en daar op te leuken, zodat je na het lezen in ieder geval weet waar je op moet letten, wanneer je jouw sim te lijf gaat om de laatste druppel performance eruit te persen… 😉

Klaar? Daar gaat ie … hoe zat het ook alweer?

Lees verder de pdf met deze link:  FlightSim-PC Performance

Graphics Stability Issues


  • Frozen appearence (short or long period)
  • Flickering

One of the most common stability problems in graphics occurs when a computer “hangs” or appears completely “frozen” while, in reality, it is processing an end-user command or operation. The user typically waits a few seconds and then decides to reboot the computer. The frozen appearance of the computer typically occurs because the GPU is busy processing intensive graphical operations, typically during gameplay. The GPU does not update the display screen, and the computer appears frozen.1530296741-p3dv3-4.jpg

In Windows Vista and later, the operating system attempts to detect situations in which computers appear to be completely “frozen”. The operating system then attempts to dynamically recover from the frozen situations so that desktops are responsive again. This process of detection and recovery is known as timeout detection and recovery (TDR). In the TDR process, the operating system’s GPU scheduler calls the display miniportdriver’s  DxgkDdiResetFromTimeout function to reinitialize the driver and reset the GPU. Therefore, users are not required to reboot the operating system, which greatly enhances their experience.

1530296745-p3dv4-3.jpgThe only visible artifact from the hang detection to the recovery is a screen flicker. This screen flicker results when the operating system resets some portions of the graphics stack, which causes a screen redraw. This flicker is eliminated if the display miniport driver complies with Windows Display Driver Model (WDDM) 1.2 and later. Some legacy Microsoft DirectX applications (for example, those DirectX applications that conform to DirectX versions earlier than 9.0) might render to a black screen at the end of this recovery. The user would have to restart these applications.


This sequence briefly describes the TDR process:

Timeout detection in the Windows Display Driver Model (WDDM)

The GPU scheduler, which is part of the DirectX graphics kernel subsystem (Dxgkrnl.sys), detects that the GPU is taking more than the permitted amount of time to execute a particular task. The GPU scheduler then tries to preempt this particular task. The preempt operation has a “wait” timeout, which is the actual TDR timeout. This step is thus the timeout detection phase of the process. The default timeout period in Windows operating systems is 2 seconds. If the GPU cannot complete or preempt the current task within the TDR timeout period, the operating system diagnoses that the GPU is frozen.

To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in user scenarios such as productivity and game play.

Preparation for recovery

The operating system’s GPU scheduler calls the display miniport driver’s DxgkDdiResetFromTimeout function to inform the driver that the operating system detected a timeout. The driver must then reinitialize itself and reset the GPU. In addition, the driver must stop accessing memory and should not access hardware. The operating system and the driver collect hardware and other state information that could be useful for post-mortem diagnosis.

Desktop recovery

The operating system resets the appropriate state of the graphics stack. The video memory manager, which is also part of Dxgkrnl.sys, purges all allocations from video memory. The display miniport driver resets the GPU hardware state. The graphics stack takes the final actions and restores the desktop to the responsive state. As previously mentioned, some legacy DirectX applications might render just black at the end of this recovery, which requires the end user to restart these applications. Well-written DirectX 9Ex and DirectX 10 and later applications that handle Device Remove technology continue to work correctly. An application must release and then re-create its Microsoft Direct3D device and all of the device’s objects. For more information about how DirectX applications recover, see the Windows SDK.

Limiting Repetitive GPU Hangs and Recoveries

Beginning with Windows Vista with Service Pack 1 (SP1) and Windows Server 2008, the user experience has been improved in situations where the GPU hangs frequently and rapidly. Repetitive GPU hangs indicate that the graphics hardware has not recovered successfully. In these situations, the user must shut down and restart the operating system to fully reset the graphics hardware. If the operating system detects that six or more GPU hangs and subsequent recoveries occur within 1 minute, the operating system bug-checks the computer on the next GPU hang.

TDR Error Messaging

The operating system also logs the preceding message in the Event Viewer application and collects diagnosis information in the form of a debug report. If the user opted in to provide feedback, the operating system returns this debug report to Microsoft through the Online Crash Analysis (OCA) mechanism.

Timeout Detection and Recovery (TDR) Registry Keys

You can use the following TDR (timeout detection and recovery)-related registry keys for testing or debugging purposes only. That is, they should not be manipulated by any applications outside targeted testing or debugging.

  • TdrLevelSpecifies the initial level of recovery. The default value is to recover on timeout (TdrLevelRecover).
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrLevel
    ValueType : REG_DWORD
    ValueData : 
    TdrLevelOff (0) - Detection disabled 
    TdrLevelBugcheck (1) - Bug check on detected timeout, for example, no recovery.
    TdrLevelRecoverVGA (2) - Recover to VGA (not implemented).
    TdrLevelRecover (3) - Recover on timeout. This is the default value.
    
  • TdrDelaySpecifies the number of seconds that the GPU can delay the preempt request from the GPU scheduler. This is effectively the timeout threshold. The default value is 2 seconds.
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrDelay
    ValueType : REG_DWORD
    ValueData : Number of seconds to delay. 2 seconds is the default value.
    
  • TdrDdiDelaySpecifies the number of seconds that the operating system allows threads to leave the driver. After a specified time, the operating system bug-checks the computer with the code VIDEO_TDR_FAILURE (0x116). The default value is 5 seconds.
    KeyPath   : registry
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrDdiDelay
    ValueType : REG_DWORD
    ValueData : Number of seconds to leave the driver. 5 seconds is the default value.
    
  • TdrTestModeReserved. Do not use.
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrTestMode
    ValueType : REG_DWORD
    ValueData : Do not use.
    
  • TdrDebugModeSpecifies the debugging-related behavior of the TDR process. The default value is TDR_DEBUG_MODE_RECOVER_NO_PROMPT, which indicates not to break into the debugger.
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrDebugMode
    ValueType : REG_DWORD
    ValueData : 
    TDR_DEBUG_MODE_OFF (0) - Break to kernel debugger before the recovery to allow investigation of the timeout. 
    TDR_DEBUG_MODE_IGNORE_TIMEOUT (1) - Ignore any timeout.
    TDR_DEBUG_MODE_RECOVER_NO_PROMPT (2) - Recover without breaking into the debugger. This is the default value.
    TDR_DEBUG_MODE_RECOVER_UNCONDITIONAL (3) - Recover even if some recovery conditions are not met (for example, recover on consecutive timeouts).
    
  • TdrLimitTimeSupported in Windows Server 2008 and later versions, and Windows Vista with Service Pack 1 (SP1) and later versions. Specifies the default time within which a specific number of TDRs (specified by the TdrLimitCount key) are allowed without crashing the computer. The default value is 60 seconds.
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrLimitTime
    ValueType : REG_DWORD
    ValueData : Number of seconds before crashing. 60 seconds is the default value.
    
  • TdrLimitCountSupported in Windows Server 2008 and later versions, and Windows Vista with Service Pack 1 (SP1) and later versions. Specifies the default number of TDRs (0x117) that are allowed during the time specified by the TdrLimitTime key without crashing the computer. The default value is 5.
    KeyPath   : registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers
    KeyValue  : TdrLimitCount
    ValueType : REG_DWORD
    ValueData : Number of TDRs before crashing. The default value is 5.
    

Source: https://docs.microsoft.com/en-us/

How reliable is your PC?


Troubleshooting

  1. Go to Start en type reliab (in W10 NL: betrouw ) in the Search Programs and Files box; give an Enter or
  2. Go to Control Panel-System and Security-Action Center-Reliability Monitor
    ConfiguratieschermSysteem en beveiligingBeveiliging en onderhoudBetrouwbaarheidscontrole
  3. This is what you get: (see above).
  4. Choose either the day or a week to get an overview.
  5. Below the graph you can see the problems that were present in a certain period of time.
  6. Use this feature to get a grip on what when happened.

Problem Step recorder:
The next handsome tool.

  1. Here’s how to record your problems on your screen.
  2. Click Start, immediately type psr, and press Enter. psr stands for Problem Steps Recorder. You can start it from the Control Panel, but this method is a whole lot easier. The Problem Steps Recorder, which resembles a full-screen camcorder, springs to life (see Figure). It isn’t recording yet.
  3. Click Start Record. The recorder starts. You know it’s going because the title flashes “Problem Steps Recorder — Recording Now.”
  4. If you want to type a description of what you’re doing or why or anything else you want your friend to see while he’s looking at your home movie, click the Add Comment button. The recording pauses and the screen grays out a bit. A box appears at the bottom of the screen that says Highlight Problem and Comment. Click the screen wherever your problem may be occurring, and drag the mouse to highlight the problematic location. Type your edifying text in the box and click OK. Recording continues.
  5. When you’re done with the demo, click Stop Record. PSR responds with the Save As dialog box.
  6. Type a name for the file (it’s a regular Zip file) and click Save.
  7. Send the file to your friend…that’s me…or somebody else.
  8. It will surely help you understand what actions you did.

 Windows Update

Do I have to explain why? No. In Control Panel-System and Security-Windows Update you will find the frequently asked questions. Take care that you have always the latest updates for your Windows 7 system on board. If an update fails, don’t panic. Wait for another day or week and retry to update.

Do you have the right patches for every program (excl. FSX) ? An answer to that question is given by Secunia Software inspector (PSI). This piece of free-ware detects and installs missing security patches for your PC. The view shows an aggregated list of programs detected on your PC with the latest Secunia PSI scan. Get it HERE, install it and take advantage of it.

About Security…use the free Microsoft Security Essentials and save your dollars for anything else.

Now we getting somewhere…

Speed is all you need. Your registry is the place where it all is registered. What’s in a name. To keep this registry clean and up to date, clean daily ! Go here and when you’re there, pick at the same time the Defraggler program.

Defrag, defrag, defrag… One file that is dragging you down in speed is the pagefile.sys and new installed scenery and textures. You cannot defrag pagefile.sys when Windows is running. For that reason, when Defraggler is launched, goto Settings>> Boot time defrag and change into  Run Once. The next time when you reboot, pagefile.sys is defragged. Defrag at least weekly. Do not defrag SSD.

Now you’re settled and waiting the errors to come…read more Unstable system – Error Resolution