Si tu sauvegarde tes VOLS via FSUIPC ? c'est peut être ça !

Patou

Un prog en arrière plan, style antivirus ?

Bonjour

J'ai au le meme problème sous FSX : freeze multiples en vol avec quelquefois écran noir.
J'ai utilisé Tweaking.com Windows Repair rubrique Repairs -> rubrique 05 Repairs Windows WMI (uniquement)
Et depuis plus de problème

A cela, j'ajouterai que j'ai eu aussi ce genre de problèmes lors d'update de Windows (téléchargement en background) au moment de son enregistrement sur sa zone. Mais, jamais une dizaine de secondes, seulement 1 ou 2 mais ça parait une éternité. Cette régularité parait bizarre.
JMC

Quelle est l'explication concernant ces interruptions?
Quand P3D est arrêté, on voit bien un trou (dans Process explorer) au niveau de la charge GPU; ou plus rien ne se passe.
J'ai refait un test en désactivant tous les addons (exe et dll.xml) et xa semble mieux marcher.
J'en ai réactivé une partie et ca marche bien encore.
Si je les réactive tous (sauf ezdok), j'ai encore quelques freeze, mais moins nombreux semble t-il.
Et si je regarde les graphes IO de Process explorer, c'est pratiquement le désert..

Sinon
Bee Gee, je suis en W7 x64$
Lagaffe: L'indexation est désactivée et les répertoires liés à P3D sont trustés dans mon AV

Merci pour vos suggestions.
Je vais continuer mes tests.

Salut tous le monde !

J'ai eu ce problème aujourd'hui ! j'ai voulu faire un vol long courrier et ce matin je me suis rendu compte que mon P3D Freezait toutes les5 secondes pendant 10 - 15 secondes aussi ! vous pensez que ça peut venir d'une analyse antivirus lancée par W10 ?

Je vais essayer d'exclure les dossiers de P3D des analyses ! ça devrait changer quelque chose ? ou faut-il plutot totalement le désactiver ?

Pour poursuivre ce fil, voici un graphique d'activité P3D issue de process explorer, qui montre plusieurs choses



Il s'agit d'un assemblage de 2 graphiques durant une exécution de P3D, lors d'un vol au départ de Dublin avec l'A320 Aerosoft: le graphique de charge GPU et le graphique de charge CPU correspondant.

J'ai assemblé les 2 en gardant la synchro temporelle.

Le graphique du haut montre l'activité du GPU. Il présente des creux quand le GPU n'est pas chargé.

Le graphique du bas montre l'activité du CPU. Il comprend une partie verte qui est celle de l'exécution (charge CPU) de P3D en mode user, et une partie rouge, qui montre l'activité du CPU en mode kernel.

On constate des pics d'activité en mode kernel qui correspondent au creux d'activité du GPU (flèches rouges). Ce sont pendant ces pics que les freezes plus ou moins longs se produisent (et donc le GPU n'est plus sollicité).

La question est pourquoi ces pics en mode kernel?

Divers outils de monitoring m'indiquent que les drivers les plus sollicités sont le driver NVIDIA en mode kernel et aussi le driver DirectX Microsoft (mode kernel)

A chaque fois que ces freezes se produisent, le taux d'activité du process "interrupts" monte vers 2-3% (au lieu de 0,2 à 0,3% normalement)

J'ai fait plusieurs tests en enlevant le maximum de processus d'arrière plan et çà ne change pratiquement rien.

Par contre, c'est liè à l'activité de P3D: si je le mets en pause, son activité diminue fortement et aussi l'activité en mode kernel et les deux forment un plateau stable. Si je sors P3D de la pause, les problèmes reviennent rapidement.

J'ai testé en reprenant un driver NVIDIA plus ancien (375.63, 23 nov 2016) et le même comportement est observé.

Concernant la VAS dans ce test, il me reste 1,3 GO de dispo, donc ce n'est pas un problème de mémoire.

Concernant la charge CPU de P3D, elle monte à 50% maximum, donc une charge moyenne.

Bref, pour l'instant je suis dans le flou...

Bon,

je crois que j'ai résolu mon problème.

En effet, croyant bien faire et améliorer les choses, j'avais fixé la priorité de P3D à "high". En fait, ce qui se poasse dans ce cas c'est que l'OS est obligé de mettre des traitements d'interruption en DPC (deffered procedure calls) pour laisser la priorité à P3D. Mais il arrive un moment ou il ne peut plus le faire et alors reprends la main brutalement pour purger ces traitements en attente.

Pour tester, j'ai mis la priorité de P3D à "plus bas que normal" et là, c'est une vraie transformation, car tous les traitements s"enchainent au fil de l'eau. S'il y a des moments de latence, ils sont très courts (stuttering) et sont alors dus à P3D dans son process propre et là il n'y a rien à y faire...

Je viens d'effectuer le même vol Dublin-Glasgow sans un seul freeze de plusieurs secondes.

Je dois confirmer encore mon hypothèse, mais je pense que j'ai compris le mécanisme.

Patricepilvirt a écrit:

Bon,

je crois que j'ai résolu mon problème.

En effet, croyant bien faire et améliorer les choses, j'avais fixé la priorité de P3D à "high". En fait, ce qui se poasse dans ce cas c'est que l'OS est obligé de mettre des traitements d'interruption en DPC (deffered procedure calls) pour laisser la priorité à P3D. Mais il arrive un moment ou il ne peut plus le faire et alors reprends la main brutalement pour purger ces traitements en attente.

Oui effectivement, hausser la priorité du process parait une bonne idée, mais windows n'est pas un OS fait pour ça. A moins de réussir à tuer tout ce qui pourrait interrompre l'application en fait.
Pour ce genre de choses il y a .... linux (mais pas toutes les versions).

J'ai essayé une fois la priorité "real time" ça a juste gelé mon système.