r.chatigré

Yes! No! (hé hé)

Un fastoche totoches!

De mon point de vue: ne jamais charger les utilitaires de carte mère si on n'en a pas besoin. Ils sont mal maintenus, mal programmés, Windows fait le taf tout seul normalement pour les pilotes.

"C'est étrange, du coup tu es sur une résolution de timer à 1ms avec ou sans latencymon...." J'ai relu le thread, et du coup je suis aller creuser certains points. Ryzen balanced: tu n'as plus ce profil qui te permettait de limiter (résoudre?) le problème. Ryzen balanced est basé sur un idée simple: maintenir TOUS les coeurs actifs même quand ils n'ont rien à faire. Ce qui correspond un peu au fait que si tu as plus de charge, tu as moins le problème. Je me demande si on ne pourrait pas "pinner" le processus de l'emulateur sur seulement 1 ou 2 CPU (cf How To Force Windows Applications to Use a Specific CPU (howtogeek.com) objectif: maintenir la charge sur 1 coeur en évitant aux threads de "s'étaler", afin que le CPU ne baisse pas de vitesse ou autre. Je chercher une solution qui ne demande pas de modifier la config du PC juste pour l'émulateur, donc une solution qu'on pourrait n'appliquer qu'à l'émulateur. J'ai aussi regarde rle code source de l'émulateur PPSSPP pour sa partie windows: pas de trace de SetTimerresolution -> je suppose qu'il tourne bien par défaut à 8 ou 16ms sur les orids des testeurs. Par contre: j'ai relu 2 fois qu'utiliser PCSX2 depuis retroarch ou un autre limite le phénomène de stuttering - j'imagine que soit retroarch maintient une charge, soit il a une config par défaut qui limite le problème. Dans tous les cas, ton ordi est très largement suffisant pour faire tourner ces émulateurs. Tu es plus dans le cas des programmes qui ne supportent pas les ordis "trop" performants (ou là: "trop" évolué)

C'est étrange, du coup tu es sur une résolution de rimer à 1ms quelque sit latencymon.... Latencymon est un truc bizarre: il s'immisce dans windows en tant que pilote pour mesurer les autres pilotes.. Il n'y a pas de raison qu'il flluidifie quoique ce soit (ou alors avec des scénarii tirés par les cheveux avec les J'ai du mal à faire le point sur ta config (PC et émulateur). Sur l’émulateur, tu es bien en vsync et l'écran est en 60hz fixe (pas de gsync ou autre taux de rafraîchissement variable)? As-tu tenté sans antivirus (c'est pas bien, mais les émulateur font de la compilation à la volée,ce qui ne plaît guère aux antivirus)? As-tu tété en lançant l'émulateur en tant qu'admin?

Du coup le résultat c'est avec latencymon en fonctionnement?

Pour vérifier, peux-tu donner le résultat de ceci (il faut le mettre dans un fichier powershell et le lancer en ligne de commande powershell) avec l'émulateur lancé avec ton utilitaire latencymon lancé (il faudra peut-être à l'invite powershell lancer la commande "Set-ExecutionPolicy -Scope Process Unrestricted" ) # # # Set-ExecutionPolicy -scope Process Unrestricted Param ([int] $resolution=-1) Set-StrictMode -v 2 $TimerResolutionApis = @' [DllImport("ntdll.dll", SetLastError=true)] public static extern int NtSetTimerResolution(long DesiredResolution, bool SetResolution, out ulong CurrentResolution); [DllImport("ntdll.dll", SetLastError=true)] public static extern int NtQueryTimerResolution(out ulong MinimumResolution, out ulong MaximumResolution, out ulong CurrentResolution); '@ $NtDll = Add-Type -MemberDefinition $TimerResolutionApis -Name 'Time' -Namespace 'NtDll' -PassThru # Vieux monde: ulong=32 bits, le 64 bit est le type "longlong" [uint32] $result = 0 [uint32] $minResolution = 0 [uint32] $maxResolution = 0 [uint32] $curResolution = 0 [NtDll.Time]::NtQueryTimerResolution([ref] $minResolution, [ref] $maxResolution, [ref] $curResolution) Write-Output "Result: $result" Write-Output "Min: $minResolution" Write-Output "Max: $maxResolution" Write-Output "Current: $curResolution" if($resolution -ge 0) { [uint32] $targetReso = $resolution Write-Output "Trying to set resolution to $resolution" $result = [NtDll.Time]::NtSetTimerResolution($targetReso, $true, [ref] $curResolution) if ($result -ne 0) { Write-Error "NtSetTimerResolution failed ($result)" } Write-Output "Current: $curResolution" }

Arf, le copier coller depuis le tel... https://youtu.be/X3ZmmebE-Kw

Je ne sais pas ce que ça vaut...

Soit en boot usb avec une clé winpe, soit avec psexec -s pour utiliser le compte system (plus de droits que admin)

Si vous faites quelque chose un jour et que vous avez un risque de perdre l'ouïe, quells seraient les 3 derniers morceaux de musique/groupe que vous écoutez? (2-3 réponses) Né en1917 à leidenstadt / Fredericks Goldman Jones Heavy duel / dire straits Seeds of love/ tears for fears

Skully?

A ben oui... logique... Mon problème, c'est qu'il est impossible de conseiller de changer d'ordi comme tu le sous-entendais car on ne sait pas ce qui cause le problème - ou plutôt le triplet écran/CG/driver peut être le problème et changer l'ordi ne le résoudra pas forcément. Finalement, sur mon fixe j'ai le 59.94Hz: c'est une TV, si je ne la met pas en mode "ordi", le 59.94Hz apparaît mais en entrelacé. --> Est-ce que logistiquement c'est possible de tenter l'expérience avec l'ordi branché sur une TV? J'ai lu aussi que certains ont des résultats en utilisant retroarch et le moteur ppsspp. Et à priori, PPSSPP peut fonctionner sur une RPI... Qui est plus maniable côté rafraichissement.

Je ne pense PS que la CG soit vieille. Ces émulateurs marchent sur à peu près n'importe quoi depuis des années. Je pars donc sur une autre piste (enfin je reprend une ancienne avec d'autres éléments): Dans ce thread reddition, le gars signale du stuttering avec handbrake à cause du déport de tâches sur les efficiency cores

Je reste convaincu du problème plutôt soft, mais qu'un tout petit changement a déclenché. J'ai recreusé des posts sur PPSSPP et PSCX2, les deux ont des réponses même par les développeurs incriminant surtout le taux de rafraichissement de l'écran et Windows (Linux dans une moindre mesure si on n'a pas les patch realtime). Les posts sont réguliers de 2013 à aujourd'hui (en 2014, 2015, 2017, 2019...) et quelque soit la puissance de l'ordi ou de la CG Dans une réponse de 2017, pour eux le problème est dans la cadence de rendu interne à 59.94Hz et les écran en 60Hz/75Hz. Le problème s'atténue à 120Hz, mais dans ce cas on reste bloqué par la précision de 1ms de Windows. As-tu moyen de caler ton rafraichissement d'écran sur un mode 59.94Hz? (moi je l'ai sur la carte Intel HD de mon portable par exemple, mais pas sur mon ordi fixe en AMD)

Elle touche VIA les entretoises (on voit généralement la ligne de masse sur une couche du dessus ou dessous. L'isoler l'exposerait à des interférences par ondes à l'intérieur du boitier. Effectivement, elle ne doit pas toucher le fond pour ne pas court-circuiter les pattes qui dépassent en-dessous. L'IO Shield EST conducteur et maintient le pourtour des prises VGA/USB/HDMI et le boitier en contact pour que tout soit à la masse pour éviter les interférences, les étincelles et les courants fuyants... Si on essaie d'isoler la CM du boitier, c'est une GROSSE erreur.

Ca se vérifie facilement 🙂 La CM devrait être reliée au chassis: par les vis par la masse de l'alim elle-même reliée au chassis par le "backplate" métallique à l'arrière Si le grésillement survient sur un casque filaire la masse peut être en cause. Si le grésillement survient sur un lien bluetooth, un problème d'interférence ou de pilote peut être en cause.

Bonjour, En général, on synchronise les heures des serveurs automatiquement, et en cas de problème de changement d'heure hiver/été, on ajuste juste l'écart avec UTC. Pour synchroniser l'heure d'un serveur: Souvent on utilise un serveur NTP, soit local et synchronisé, soit un NTP du net. Ces serveurs envoient l'heure périodiquement. Si l'ordi dérive, il se synchronise "lentement" (en réduisant/allongeant les secondes par exemple). Par exemple, sous Windows les serveurs AD sont souvent les NTP. Si le serveur est virtuel, on peu synchroniser l'hôte, et les serveurs invités utilisent alors l'heure de l'hôte (c'est une option des VM) Sous Linux, installer le package ntpdate et le configurer fera l'affaire. En cas de proxy/firewall, il va falloir permettre de passer au travers pour le serveur et le protocole NTP. Remarque: la synchro des ordis et serveurs est essentielle dans un environnement AD.

Ok, donc ce sont bien des grésillements analogiques, on peut oublier ce que j'ai dit avant. Il faut mettre ton ordi à la masse, tu as peut-être des rondelles isolantes qui isolent ta CM de la carcasse, des trucs du genre. Un petit bout de fil devrait régler ce problème de grésillement, ou alors tu as un problème de terre sur ta prise électrique.

Non, ça montre que le bug est dur à traquer car il est toujours signalé en Novembre 2022. C'est visiblement des problèmes de timings, donc c'est une combinaison complexe (CPU, GPU, paramétrage, peut-être écran et carte son). On parle d'émulateur HLE là, ce sont des émulateurs qui doivent artificiellement maintenir la synchro vidéo/audio/cpu, là où les émulateurs plus basique sont plus lourds, mais vont généralement instrinsèquement respecter la synchro. Ca a toujours été touchy, dès UltraHLE pour la N64. Les performances de l'ordi deviennent secondaires à un moment, c'est la performance de chaque opération (lecture buffer audio, envoi d'image) et surtout de tout ensemble qui compte. Alors ça c'est super important! Les problèmes de contrôleur USB peuvent parfaitement suspendre l'ordi le temps d'un reset de la chaîne USB! Surtout que normalement il ne devrait pas se produire des grésillements, mais des "glitch", des sautes ... un peu comme pour ton framerate. 10ms de pause dans le son, c'est immédiatement détecté. 10ms de pause dans l'image, ce n'est pas toujours visible... Un grésillement dans le son USB, c'est une saute permanente en fait. Tu es en bluetooth pour l'audio? As-tu installé des pilotes de carte mère? Si oui, désinstalle les. Utilise Rapr/DriverStoreExplorer pour supprimer les pilotes. Laisse Windows installer ses pilotes. Supprime les contrôleurs USB dans le gestionnaire de périphériques en supprimant aussi les pilotes et redémarre

Très peu probable. Une corruption de FS, c'est deux possibilités: Problème du disque Pilote/soft très bas niveau douteux (donc le RAMDisk III est un bon candidat) NTFS ne se fait pas corrompre si facilement. L'énorme majorité des interruptions brusques pendant une écriture n'a aucune incidence. Les tables des fichiers sont en double, c'est journalisé (il déclare des intentions d'écritures et ne les marque faites que si l'écriture est terminée - donc en général au pire en cas de coupure il va écrire 2 fois la même chose sans incidence). Reste la possibilité lors de l'écriture de la copie de la structure des fichiers: dans ce cas il détecte que les copies ne sont pas conformes et les vérifies par rapport à la structure réelle... Sérieux, un NTFS vérolé, ça peut arriver mais ça ne sent pas bon du tout, c'est un produit tout aussi fiable que ses concurrents sérieux. Tu as plus facile à péter un BTRFS sous Linux (pas de bol moi), alors qu'il est déjà très bien.

Tu peux utiliser une clé USB avec "DUET /w refind" ou "Clover boot loader" Clover EFI bootloader download | SourceForge.net qui permettent de booter des disques NVMe même sur un PC qui n'a pas de boot NVMe. Injecter un pilote NVMe dans ton bios est peut-être possible, mais tout ça pour un émulateur... Paramétrer le boot manager Windows et installer Windows 10 dans un fichier VHD sur le disque est aussi une bonne solution Je signale aussi que sur git des émulateurs, ce type de stuttering n'est pas lié à l'OS, ils l'ont aussi sous Linux... --> mieux vaut plussoyer les bugs git pour qu'ils s'en occupent!!!

Et en plus le fonctionnement est 'dangereux' en cas de plantage de l'ordi ou de reset/coupure brusque. Ce soft est ultra douteux et un potentiel vecteur de problème d'écritures partielles de fichiers. Je ne pensais pas que les fabricants mettaient encore de genre de soft bien nase en bundle. Ca sent le partenariat avec une boite de soft en train de couler car son truc n'a aucun intérêt réel (windows et le pilote intel font le taf, et ont aussi les options dangereuses mais en opt-in) mais bon ça n'explique pas forcément l'erreur disque car pour casser un NTFS, il faut se forcer...

Normalement C:\ est en NTFS, ça ne se corrompt pas comme ça (pas depuis NT3.51) Utiliser un outil comme crystal disk mark pour vérifier la santé du disque Vérifier l'état du disque avant démarrage via un "fsutil dirty query" Eviter les jeux avec des anticheat trop intrusifs (malheureusement, c'est difficile)

J'ai vu cela (bon, ça date d'il y a 10 ans): Strange micro stuttering (FFIV) (ppsspp.org) Et ceci (il y a 1 an): [FR] Sync to host refresh rate to prevent micro-stuttering · Issue #15081 · hrydgard/ppsspp · GitHub Et ceci (il y a 1 mois): [BUG]: Stutter/Frame pacing issues in multiple games · Issue #7485 · PCSX2/pcsx2 · GitHub Dont une réponse: Locking the GPU Core and Memory frequencies for PCSX2 seems to have solved the random slowdowns I was experiencing as well as most of the incorrect frame pacing occurrences. En gros, deux phénomènes sont connus: le upscaling des textures: les textures sont lues depuis le disque et upscalées à la demande. Selon le niveau d'upscaling cela peut impacter à la fois la charge CPU et la charge graphique (transfert mémoire) ils font super attention au framerate à la virgule près (ou plutôt, à deux décimales près). Donc il y a de la récupération selon les options de synchro verticale.