Réunion du 12-11-2024

Changements du code de la semaine

• Sortie d'OpenSimulator 0.9.3.0
• Commit 24cbfb : Changement de version de développement, OpenSimulator 0.9.3.1Dev

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Base de données

Migration

• Vincent Sylvester a testé le nouveau système de migration de la base de données . Cela lui a donné des informations utiles sur certains oublis.
• Le système semble prometteur, il faudra encore quelques semaines de tests en production et il devrait être prêt pour qu'Ubit Umarov l'intègre au code.

Informations

OSCC 2024

• Formation des conférenciers : samedi 16 novembre à 9h00 AM fuseau horaire PST (heure normale du Pacifique).

Maintenance de la grille Osgrid

• La réunion n'a pas lieu sur Osgrid qui est hors-ligne pour une maintenance.
• Extrait des informations trouvées sur le site d'Osgrid et traduites dans DeePL [1]:

Nous sommes actuellement en mode maintenance sur OSgrid. Cela signifie que la grille est hors ligne. Pour faire court, notre cluster de stockage était apparemment à court d'espace. Notre cluster utilise ceph. Il s'agit du service de stockage d'objets pour le système de fichiers distribués Ceph. Il gère les données sur le stockage local avec redondance et fournit un accès à ces données sur le réseau. Ce démon écrit vos assets sur le disque dans de minuscules paquets. Aujourd'hui, OSgrid dispose de 17 ans de données, ce qui représente environ plusieurs centaines de millions d'actifs.
[...]
Date de mise en œuvre du correctif ? 
Dès que possible en ce qui nous concerne. Nous ne voulons pas casser ou négliger des choses en nous précipitant, ni remettre les choses en ligne trop tôt et bloquer le processus. Nous pouvons le mettre en ligne, mais l'expérience nous a appris que ce n'est pas parce que les choses sont possibles qu'elles sont nécessairement intelligentes.
[...]
Pourquoi cela prend-il autant de temps ? Cela prend du temps parce qu'il s'agit simplement d'une grande quantité de données et que la machine fait ce qu'elle peut. 
[...]
Avons-nous perdu des assets / allons-nous en perdre à cause de cette opération ? Rien ne doit être perdu ! Techniquement. Charger et réécrire des données et les enregistrer à nouveau ne devrait pas causer de problèmes dans le cadre d'opérations normales. Nous étions conscients du problème et nous l'avons résolu avant qu'il ne devienne incontrôlable.

• Il n'est pas certain qu'Osgrid soit de retour pour la prochaine réunion.

Plateformes  : utilisation CPU avec Mono vs Dotnet

Mesure de l'utilisation du CPU dans OpenSim

• Jusqu'à présent, la version dotnet d'OpenSim a montré une réduction globale de l'utilisation du processeur de 50%, ce qui est assez important.
• Dans le monde virtuel (In World) il n'existe pas de fonction LSL directe pour tester l'utilisation du CPU.
• La fonction indirecte que Vincent Sylvester utilisait avec Mono ne fonctionne plus avec Dotnet. Les chiffres rapportés sont incorrects. Il comparait le temps de réponse du processeur. Cela semblait précis sous Mono. Dotnet rapporte maintenant des valeurs beaucoup plus faibles.
• Maintenant, il faudrait prendre en compte le nombre de processeurs ou de threads, ce qui complique les tests.
• Sur Windows, il existe des outils de diagnostic qui fournissent des informations directes, mais cela n'est pas indépendant de la plateforme.Donc, ils ne sont pas utilisables sous Linux.
• Vincent Sylvester va éventuellement utiliser les raycasts pour faire ces tests.

NDLR  : Utilisation de raycasts : Il est possible qu'en utilisant des raycasts, Vincent Sylvester puisse simuler une charge de travail en lançant de nombreux rayons simultanément, ce qui pourrait augmenter l'utilisation du CPU et aider à évaluer les performances du serveur.

Génération de tuiles de carte

• Ubit Umarov propose d'utiliser la génération de tuiles de cartes pour tester le CPU. Mais c'est un thread unique qui s'en tient au maximum à 100% du CPU.
• À ce propos, Vincent Sylvester dit qu'il pourrait peut-être paralléliser certaines tâches mais il n'a pas encore beaucoup étudié Warp3D et c'est difficile de comprendre la trigonométrie de ce module.
• Il pense aussi que sans avoir fait quoi que ce soit, dotnet a amélioré la vitesse de génération des tuiles de carte.
• Le module de carte intègre peu de cache, Vincent Sylvester se demande si le fait de mettre en cache les résultats du rendu des objets et de ne rendre que les objets modifiés n'améliorerait pas les performances au moment de l'exécution.

Scripts

• Les scripts semblent plus réactifs avec dotnet, probablement parce qu'ils traitent plus rapidement la file d'attente des actions qu'ils demandent d'exécuter, de sorte qu'il y a moins de « pile » à parcourir avant d'obtenir un résultat.
• Cette amélioration est certes liée à dotnet mais elle est liée également à l'amélioration du code de la version 0.9.3 d'OpenSimulator.

Gestion des surcharges

• Mono [2] gérait les surcharges de manière à ne pas bloquer le système.
• Dotnet pourrait permettre à des scripts mal conçus de provoquer des blocages plus graves. Certains scripts SL sont connus pour cela, il suffit de quelques uns pour bloquer une région.

Compatibilité des scripts SL avec OpenSim

• Avec dotnet la gestion des scripts est plus efficace, ce qui peut permettre d'atteindre un tickrate plus élevé ou de mieux gérer les scripts gourmands en ressources. Si le tickrate d'OpenSimulator pouvait être synchronisé avec celui de SL, cela pourrait améliorer la performance des scripts et réduire les problèmes de compatibilité pour les utilisateurs qui utilisent des scripts conçus pour SL. Cependant, cela dépendrait également de la qualité de la conception des scripts eux-mêmes.

NDLR  : Le tickrate fait référence à la fréquence à laquelle le serveur exécute les mises à jour de la simulation du jeu, mesurée en hertz (Hz). Il détermine combien de fois par seconde le serveur traite les événements, met à jour l'état du monde virtuel et gère les interactions entre les utilisateurs et les objets. Tickrate utillisé par Vincent Sylvester : nombre maximum de commandes ou d'actions qu'un script peut exécuter par image (frame) ou par tick.Cela correspond à la capacité de traitement des scripts.

• Vincent Sylvester indique que les scripts n'ont pas de tickrate au sens traditionnel, mais qu'il est possible d'estimer un "tickrate" basé sur la fréquence à laquelle les scripts peuvent exécuter des actions. Il explique qu'en utilisant un timer rapide et en divisant le nombre d'itérations par llGetTime()[3], on peut estimer un "tickrate" pour un script, bien que ce ne soit pas un tickrate officiel. Même si les timers ont un interval minimal, il mentionne que les scripts qui atteignent cette limitation sont souvent mal conçus.
• Second Life (SL) : Le tickrate est fixé à 15 Hz, ce qui signifie que le serveur met à jour la simulation 15 fois par seconde.
• OpenSimulator : Le tickrate par défaut est de 10 Hz, mais il peut être ajusté dans la configuration. Un tickrate plus élevé peut améliorer la réactivité, mais il est important de noter que des scripts mal conçus peuvent entraîner des problèmes de performance, notamment des blocages du simulateur.

Différence d'architecture de traitement

• Sur Second Life les scripts fonctionnent sur un moteur à thread unique, exécutant des morceaux de scripts à chaque battement de cœur (heartbeat).
• OpenSimulator (ndrl : avant l'utilisation de dotnet, donc avec Mono ?) utilisait une approche multi-threadée, lançant de nombreux threads sans garantie de gestion efficace, ce qui pouvait entraîner des blocages, notamment à cause de l'utilisation de llSleep.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-11-12