Je suis aussi en HT OFF depuis près de deux ans , je n'ai pas du tout pensé à réessayer sur on.
J'ai toujours pensé que le code de base devait être celui de FSW plutôt que celui d'FSX.
Mais cela fait quant même un peu rafistolages surtout si l'on compare au moteur d'Aerofly.

Dernière modification par Barnstormer (26-08-2022 17:58:46)

Daube a écrit:

Je ne pense pas que la carte graphique joue le moindre role dans le modèle de vol/physique du simu.
C'est plutôt ta perception des mouvements qui pourrait être affectée par un manque de fluidité de l'image, je pense.

Quand à la présence du simu sur le même SSD que Windows, il me semble que c'est plutôt une mauvaise idée. Un SSD dédié reste la meilleure solution à mes yeux. Par contre il faut bien faire attention aux réglages de la mémoire virtuelle (pagefile, sur quel disque, quelle taille), ainsi qu'aux paramètres d'exclusions de l'antivirus.

Bonjour à tous.

Cette partie du poste m'intéresse.

D'abord ma config est dans ma signature et je sais déjà qu'elle est un peu limite pour MSFS mais ça passe

- Windows 10 est sur la première partition d'une disque SSD Samsung 860 EVO 1 To
- MSFS (partie téléchargé) est sur la troisième partition d'un autre disque SSD Samsung 870 QVO 1 To
- Community sur un disque externe Seagate Expansion SCSI en USB

1°) Pensez vous que mon installation de MSFS soit judicieuse ?
2°) Comment avez vous justement paramétré les réglages de la mémoire virtuelle pagefile ?
3°) Y a t'il un moyens "d'optimiser" ma CG pour cagner un peu (pas en fluidité mais en netteté) ?

Concernant la mémoire virtuelle voivi ce que j'ai:



Merci d'avance pour les infos que vous pourriez me donner.

Bonne journée
David

La mémoire virtuelle c'est pas un truc hérité du passé pour les config dotées d'un minimum de mémoire vive hardware afin de faire tourner plusieurs applications gourmandes en RAM?
De nos jours les configs de simu ont au minimum 16 ou 32Go donc je m'étonne encore de voir ce genre de discussion car pour moi cela n'a plus d'utilité pour l'application qui nous importe ici (i.e. faire tourner MSFS)

@Ydelta,

J'ai du commencé à m’intéresser à Windows du temps de la version NT 3.51 soit aux environs de 1995 puis j'ai travaillé plus de 30 ans dans l'administration de ces systèmes tout en me spécialisant en Linux et les applications embarquées.

a)  Windows est un système multitâches et à temps partagé donc il est capable de faire tourner plusieurs applications en même temps et être suffisamment réactif pour commuter de l'une à l'autre. C'est ce que l'on attend d'un PC de bureau.
b)  Linux permet de réaliser aussi ce genre de tâches mais on peut le spécialisé pour faire de l'embarqué, c'est-à-dire un système plus ou moins dédié à une application. C'est dans ce cadre que j'ai étudier Linux pour les besoins de THALES, même si il existe des systèmes Linux plus spécialisés comme RTLinux pour le temps réel.
c) Ce que j'ai pu voir au cours de ces années, c'est que Windows au démarrage s'accapare presque toute la mémoire RAM de disponible pour mettre un maximum de données en cache et permettre cette réactivité avec plusieurs applications.
Bien sur, avec 32 Go de RAM, on peut parfois s'affranchir de pagefile mais en utilisant MSFS, on s’aperçoit que sans pagefile et même avec beaucoup de mémoire, il y a certains couacs dans le fonctionnement ... Après on peut toujours passer à 64 Go voire 128 Go mais c'est une autre histoire.

Dans le cas de David avec sa configuration (i5 2500K, 16Go de RAM et une GTX 1660) il est un peu ric-rac, je pense que sa configuration ferait tourner beaucoup mieux MSFS avec un pagefile que sans.


@David,
A l'origine les gars de Microsoft ont conçu le pagefile dynamique de manière à ce que le système puisse faire évoluer le pagefiele en fonction des besoins de l’utilisateur. A cette époque (1995) les disques durs étaient beaucoup moins gros (40 Go voire 80 Go étaient la norme) donc un pagefile dynamique permettait de faire varier ce fichier sans trop impacter les capacité de stockage.
Actuellement, ce point n'est plus d'actualité donc l'aspect dynamique n'est plus aussi important.

Ensuite, il faut essayer de réfléchir çà ce système dynamique, ce fichier pouvant évoluer en fonction des besoins, lorsque Windows trouvera qu'il faut faire grossir/réduire ce fichier, il faudra donc qu'il interrompe les tâches en cours, qu'il sauvegardes les pages dans le pagefile puis qu'il supprime le fichier et qu'il en recrée un en fonction de la place disponible : cela prends du temps selon ce qu'il y a à faire.
Dans un simulateur, le temps de réponse est très important (la preuve le sujet initial de la discussion portant sur la fluidité du modèle de vols et la réactivité des commandes). Si le système perd du temps pour ce genre de tâches, cela se ressent obligatoirement sur le simulateur.
Rappel: j'ai travaillé de nombreuses années sur des systèmes Linux dédiés qui ne faisaient tourner qu'une voire deux applications dédiées.

Il va de soi que prendre une valeur minimale égale à la valeur maximale, concoure à optimiser ce fonctionnement sans trop le perturber (point c).

Ce que tu peux lire sur "certains sites", c'est de la vulgarisation de bas-étage donc pour un public très vaste sans entrer dans le genre de détails que l'on aborde ici.
Lire ce genre de documentation est un plus mais réfléchir à comment nos systèmes fonctionnent et le but qui leur est fixé est tout aussi important et honnêtement à la portée de chacun d'entre nous: il suffit de réfléchir un peu et d'essayer de comprendre le fonctionnement d'un simulateur, c'est-à-dire :

un système le plus réactif possible en fonction des commandes qui lui sont envoyé pour obtenir en sortie un visuel aussi réactif que possible pour "donner l'illusion de la réalité".

J'ai essayé de détailler un peu mais je pense que ces éléments ne sont pas hors sujet, ils permettent de voir un peu mieux ce qu'il y a sous le "capot" et de comprendre les modifications suggérées. Après chacun est libre d'être d'accord ou non avec cela, c'est juste le fruit des mes 40 années de boulot dans des systèmes semi temps-réel :
- temps de réaction maximal  admissible la dizaine de millisecondes,
- le tic (le cadencement par le quartz sur la carte mère) d'un noyau Linux pouvait être paramétré à 10 microsecondes au minimum (sur les systèmes que j'ai construis).

Oulàlà Didier,  NT c'est bien vrai,  ça me rappelle que notre premier ordinateur pour la CAO (1986) était un MicroVax sous UNIX !!!
EDIT  : je crois même que c'était plutôt sous AIX (IBM).
Ou ULTRIX (C'était une MicroVax II de DEC).

Dernière modification par Armand42 (28-08-2022 11:01:05)

Ah, bein je ne la connaissais pas celle-ci.
Pour voir l'évolution, à l'époque je crois que le MicroVax avait 8Mo de mémoire...
J'arrête je suis hors sujet.

Dernière modification par Armand42 (28-08-2022 11:24:38)

Bonjour à tous.

Sans faire trop de HS, je suis globalement d'accord avec l'analyse de Didier sur l'utilisation du swappfile / Windows.
Pour info, je pense que je suis presque de la même génération et j'ai eu l'occasion de gérer des parcs de milliers de serveurs Windows dans plusieurs grands groupes français depuis Windows NT 3.1 en 93 (27 disquettes 3,5 pouces à l'époque ...) jusqu'à du Windows 2019, fin de mon activité pro.

Je rajouterai juste un point par rapport à l'usage de la mémoire vive et virtuelle :
La recommandation Microsoft sur les premières générations de Windows était : Fichier de swap = 1,5 à 2x la mémoire vive.
Mais depuis Windows 2008 R2 et surtout Windows 2012 (donc Windows 7 pour les postes) cf : https://www.toutwindows.com/historique-de-windows/, le choix de Microsoft a été de plus fortement solliciter la mémoire vive par l'OS du fait du moindre coût au Go de RAM et du passage en 64 bits.
Par ailleurs sur des serveurs ayant 32 Go de RAM ou plus (j'ai travaillé sur des conf avec 196 Go et plus de RAM), il n'était plus raisonnable d'avoir autant de swap.
Donc Microsoft recommandait au moins 64 Mo sur le disque C: (minimum requis pour un mini dump) ou plutôt 8 à 16 Go dont 64 Mo sur le C: .
(Informations issues de nombreux échanges avec le support Microsoft Pro).


Après est-ce que cela modifie profondément le fonctionnement et les performances de MSFS / Windows 10 ou 11 ? ... je n'en suis pas sur.

=> Bons vols à tous.

Christophe

Dernière modification par cede69 (28-08-2022 12:49:34)

Avec Google on arrivait parfois à trouver l'origine du pb avec les dumps. A condition qu'elle ait déjà été trouvée.  Par ce que utiliser les données brutes... effectivement y en a peu qui sauraient.

Ta 1660Ti est a peu près équivalente en puissance à une 1070, beaucoup de personne utilise MSFS parfaitement bien avec ce type de config ,
il faut juste que tu restes en écran et que tu baisses un peu les curseurs .
Je pense que ta ram est trop juste 16go c'est pas assez passe à 32.

Dernière modification par Barnstormer (29-08-2022 09:05:18)

Barnstormer a écrit:

Ta 1660Ti est a peu près équivalente en puissance à une 1070, beaucoup de personne utilise MSFS parfaitement bien avec ce type de config ,
il faut juste que tu restes en écran et que tu baisses un peu les curseurs .
Je pense que ta ram est trop juste 16go c'est pas assez passe à 32.

Bonjour,

Je pensais justement passer de 16 à 32 GO.

Je suis passé chez LCDC et d'après le vendeur, les barrettes actuelle n'iraient pas sur ma CM. De même de que de changer mon processeur n'est pas compatible.

David

@7473doudou,

Il y a un petit logiciel bien pratique qui permet de tout savoir sur ce qu'il y a dans son PC : AIDA64

Il est simple d'utilisation et ne nécessite aucune connaissance particulière en informatique.
Le logiciel est gratuit les 30 premiers jours ; il se trouve ici

Speecy est gratuit même après 30 jours et donne une mine de renseignements.

Téléchargement:
https://www.pcastuces.com/logitheque/speccy.htm

En savoir+:
https://fr.wikipedia.org/wiki/Speccy