Forum Flightgear France

Une communauté prend son envol

Vous n'êtes pas identifié(e).

Annonce

Futur nouvel inscrit, tu dois au préalable lire l'intégralité des 10 articles des règles, s'il te plaît. Tout nouveau compte qui ne respecte pas les règles sera supprimé par l'administration.

#1 16/11/2020 3:20:59

jano
Moderateur
Inscription : 13/11/2007
Messages : 949

vol en multiplayeurs, analyse et réglages (lag)

Je vais parler ici des outils présent dans flightgear pour améliorer l'expérience en mp, surtout la façon de diagnostiquer puis traiter la correction de lag.

part1: pilot list

Depuis un certain temps, le menu pilot list intègre une page appellée "lag" (qui s'obtient en clickant sur "IM" en haut le 3eme ètant "SI", unités métriques)

un exemple:

menu_lag_pilotlist.jpg

Pour ce soir je ne parlerai que de la colonne "lag-pps", qui donne en gros le nombre de paquet par seconde que vous recevez de chaque pilote, on a pour habitude d'en envoyer 10 par seconde, car c'est un bon compromis entre la taille du flux reseau, et la fluidité des avions mp  (j'en reparlerai plus tard )

Sur le screen, on y voit, en plus du cockpit dépassé du F-4N tongue que 4 pilotes sont à 10 pps, probablement sur le même mpserver sans perte de paquets, donc pour eux c'est tout bon.
F-LCAS subit une perte de paquet (à supposer qu'il emet bien à 10 pps) avec son 6.6. Ça demanderait de tester plusieurs mpserver pour voir si c'est liè à la partie flightgear-le web, ou si un lien particulier menant au serveur. ça peut être simplement un wifi un peu mauvais ou une BP utilisée à fond et faisant de la perte de paquets non vitaux.

Et enfin c'est la cata pour F-PTCZ big_smile en plus d'avoir choisi de faire crasher FG en affichant tous les WP du vol, on ne reçoit qu'un paquet toutes les 2 secondes, signe de l'utilisation d'un mpserveur différent, et d'une mauvaise comunication entree eux (absence de relai  "complet" en place, on a seulement la partie signalement des pilotes entre serveurs à 1pps)  Rassurez vous, il me semble qu'il a changé de serveur ensuite smile

Visuellement, une mauvaise liaison se traduira par un avion qui "saute" en l'air, le rendant plus difficile à suivre en vol en formation le pire étant lors des virages à "g"

C'est la raison principale pour laquelle il vaut mieux tous être sur le même mpserveur !

Je rappelle qu'il est possible de changer de mpserveur sans relancer FG, dans le menu multiplayer, prenez par contre l'habitude d'attendre au moins une 15aine de secondes entre la déconnexion et la reconnexion, sinon certains de vos paquets trainentt encore dans les tuyaux, et certains mpserver refusent alors de vous prendre en compte venant d'un autre endroit, la sanction est rapide, tous les autres pilotes disparaissent !

Prenez le temps de checker cette page sur pilot list a chaque fois que vous avez un doute, ou au départ de chaque meeting ,et n'hésitez pas à changer de mpserver pour trouver celui qui marche le mieux pour tout le monde.

La prochaine fois, il sera question de la colonne "lag-ms" qui est lié à la nouvelle façon qu'a FG de corriger la latence.

d'ici là, bon vols à 10pps (au moins) !


jano

Hors ligne

#2 16/11/2020 15:58:02

F-PTCZ
Membre
Lieu : LFPN
Inscription : 4/03/2020
Messages : 192

Re : vol en multiplayeurs, analyse et réglages (lag)

Bonjour Jano,

merci pour cette analyse très pertinente. En effet, j'ai fini par me rendre compte que mon problème venait de l'affichage de la route avec tous les WP, mais je vois pas comment faire autrement pour suivre la route sur un avion à plus de 300 kts, à basse altitude...

Laurent


Laurent, élève PPL à l'ACOP (LFPN)
Version FG 2020.3.1
MaC OS 10.15.7, Processeur 3 GHz Intel Core i5 6 cœurs, Mémoire 8 Go 2667 MHz DDR4, Carte Radeon Pro 560X 4Go
FG Callsign : F-PTCZ

Hors ligne

#3 17/11/2020 1:08:34

jano
Moderateur
Inscription : 13/11/2007
Messages : 949

Re : vol en multiplayeurs, analyse et réglages (lag)

tu fais comme moi, tu suis celui qui connait le parcours tongue , ou simplement le fleuve ...
la carte aussi en affichant le traffic aide pas mal ...
j'ajoute qu'un faible nombre de pps peut aussi venir d'un fg a genoux ne donnant que peu de fps .

Hors ligne

#4 17/11/2020 1:58:50

jano
Moderateur
Inscription : 13/11/2007
Messages : 949

Re : vol en multiplayeurs, analyse et réglages (lag)

part 2: lag-ms

Là, je ne sais pas si j'aurai encore tout le monde à la fin,  mais on va essayer de faire simple smile

On part du principe que l'on veut corriger la latence, et donc afficher les autres dans le futur parce notre truc, c'est le vol en formation big_smile (pour les autres, vous pouvez retourner regarder TF1 tongue )


la valeur "lag-ms" est la différence de temps entre notre temps réèl utc (celui de notre pc), et celui indiqué dans le paquet au moment ou on le reçoit (celui du pc du pilote mp, plus le temps de trajet) Un nombre négatif indique que le paquet est en retard, ce qui parait normal vu qu'il a du voyager.
Le principe est vraiment simple, si toutes les horloges des différents pilotes sont synchro, on ne corrige pas un temps de latence fixe, mais on utilise un temps commun, et on affiche dans le futur les autres pilotes, pour les amener à notre valeur du temps, du coup la synchro est vraiment bonne, et ne demande pas d'ajustement aléatoire, juste d'avoir des horloges synchro raisonnablement.

Pour savoir si deux pilotes sont synchro, la valeur de lag-ms de l'un pour l'autre doivent être du même ordre, il peut exister une petite différence, (ça dépend un peu des fps par ex) une fourchette de 20ms me parait pas mal.

Dans le cas du screenshot, ctesc35, F-GTUX et F-PTCZ ont l'air bien, avec des valeurs qui correspondent à un ping sur un mpserver (dans les 50ms de lag) ou deux mpserver reliés (le 110ms de F-PTCZ) je les soupçonne d'utiliser un serveur de temps sur leur PC/Mac, ce qui est mon cas.

on peut se servir de cette valeur pour trouver le mpserveur le plus rapide, en cherchant celui qui donne la valeur la plus proche de zéro pour les nombre négatif, c'est un peu équivalent à faire un ping.

Pour F-LCAS, c'est un peu particulier, son horloge n'étant manifestement pas à l'heure (peut être une demi seconde de décalage, me souvient plus smile ) je lui ai fait corriger son temps utc dans FG au début du vol, mais il subit une dérive et de 70ms au début, il terminera à plus de 140, alors que les valeurs des trois autres pilotes resteront stables.

la prochaine fois je parlerai de la manière de corriger son temps, et de ce qu'il se passe si on ne le fait pas ...

Hors ligne

#5 17/11/2020 12:18:26

F-PTCZ
Membre
Lieu : LFPN
Inscription : 4/03/2020
Messages : 192

Re : vol en multiplayeurs, analyse et réglages (lag)

jano a écrit :

Dans le cas du screenshot, ctesc35, F-GTUX et F-PTCZ ont l'air bien, avec des valeurs qui correspondent à un ping sur un mpserver (dans les 50ms de lag) ou deux mpserver reliés (le 110ms de F-PTCZ) je les soupçonne d'utiliser un serveur de temps sur leur PC/Mac, ce qui est mon cas.

Salut Jano, ne sachant ce qu'est un serveur de temps, je ne saurais ni te confirmer ni t'infirmer....c'est peu comme M. Jourdain et sa prose....

En tout cas, merci pour cette vulgarisation !


Bonne journée

Laurent


Laurent, élève PPL à l'ACOP (LFPN)
Version FG 2020.3.1
MaC OS 10.15.7, Processeur 3 GHz Intel Core i5 6 cœurs, Mémoire 8 Go 2667 MHz DDR4, Carte Radeon Pro 560X 4Go
FG Callsign : F-PTCZ

Hors ligne

#6 17/11/2020 12:35:18

inexel0853
Membre
Inscription : 10/10/2020
Messages : 28

Re : vol en multiplayeurs, analyse et réglages (lag)

Salut Jano

En effet si tu pouvais me donner la recette absolue pour corriger cette erreur d'horloge que tu as détectée et qui se serait aggravée pendant le vol malgré la correction initiale, je suis preneur.

Vient-elle de mon PC portable ou de la carte graphique qui n'est manifestement pas optimale/suffisante pour FG?

Cordialement

Laurent
F-LCAS


Windows 10, 64 bits, Intel Core i5-4310M CPU 2.70 Ghz RAM 4 Go Carte Graphique Intel HD Graphics 4600
FG 2020.1.1 - Thrustmaster T16000M / TWCS-Throttle  - Callsign: F-LCAS

Hors ligne

#7 17/11/2020 22:35:23

jano
Moderateur
Inscription : 13/11/2007
Messages : 949

Re : vol en multiplayeurs, analyse et réglages (lag)

Alors en premier, que se passe-t-il si on a pas une horloge synchro?

Ben pas grand chose , on se retrouve simplement à utiliser le code d'avant, qui corrige d'une latence fixe réglable dans le menu lag du screen. donc en cas de correction de lag activé, les positions respectives des avions seront moins bonne qu'en utilisant le mode décrit plus haut que j'appelle "temps réel".

Et si la correction de lag n'est pas votre priorité, désactivez la, et les autres avions seront plus fluide, mais sans concordance spaciale.

Maintenant, pour Laurent qui ne veut pas ruiner son expérience de vol en patrouille smile il existe plusieurs solutions:

1) utiliser un service qui asservi l"horloge de la bécane sur des serveurs de temps internet (network time protocole), j'utilise ntp sous linux qui doit se trouver sous mac, et le ntp de meinberg marche pas mal sous windows. Il interroge régulièrement les serveurs de temps, et corrige l'heure en fonction, permettant par la même de s'occuper de la dérive de l'horloge.
J'ai écrit le code mp avec dans l'idée d'utiliser cette solution en priorité, vu que ça sert à rien de recréer la roue et que la précision est suffisante pour mon besoin .

Il est aussi possible d'avoir un gps qui sert de référence ou il existe un protocole dédié aux lan (ptp) que je ne détaillerai pas smile

2) Aider les dev à écrire un peu de nasal pour recaler régulièrement son horloge sur les pilotes qui se disent utilisant ntp, c'est dans ma todo list, mais ma période de codage ne dure que la période la plus sombre de l'année, autour de noël smile
À ce moment là il serai possible de rester pas mal synchro sans forcément utiliser ntp, mais c'est encore seulement dans les cartons smile

3) le faire régulièrement à la main en ajustant son offset et faire redescendre le lag du pilote de référence à la valeur trouvée au début par comparaison (ce qu'on a fait au début du vol)
Ah oui la correction est accessible dans le menu multiplayer => lag correction settings  c'est "clock offset" il faut faire attention que sa valeur est en secondes, alors que "lag-ms" est en .......... ms !

un cas pratique , qui demande un peu de dialogue entre les deux pilotes:

le c172p voit un c182 avec un lag de -210, le c182 voit le c172p à +70, la valeur équilibré entre les deux est leur moyenne : (-210+70)/2 = -70 ms, donc il faut corriger de 140ms, si le c172p utilise ntp, le c182 ajoute +0.140 en offset, si c'est l'inverse, le c172p mets -0.140 et si chacun veut faire la moitié de la correction, un met +0.7, l'autre -0.7, et je vous laisse trouver qui fait quoi !


Pour continuer l'analyse du screen du haut, AF-MA13 a une horloge en avance de l'ordre de la demi seconde (440 alors qu'il  devrait être dans les -60) et rity65 est en retard de 138 secondes, un moment qu'il a pas mis son pc à l'heure de l'horloge parlante smile


Je rappelle que un tel pointillisme n'est nécessaire que si vous avez besoin de ce mode "temps réel", et que c'est du code assez jeune toujours en développement, mais pour ce que je vois des autres pilotes dans FG, pas mal de pilotes utilisent un serveur de temps et ont des valeurs de lag cohérentes et stables sur le long terme, même d'une session à une autre donc le modèle marche pas mal, même si il reste des amélioration à apporter afin de le rendre plus convivial à l'utilisation et visuelement en mp.

Pour finir, dans le menu "correction de lag" du screen, il faut avoir coché "Master switch" et "apply to close mp" pour que le code temps réel s'active quand les horloges sont assez proches, je pense qu'il subira quelques modif cet hiver, donc affaire à suivre smile  Pour le moment c'est la période de test, afin de voir quoi améliorer tongue

Je vous laisse jouer un peu avec l'offset et on fera un travail pratique un de ces jours smile vous voila au point sur le diagnostique réseau de FG !

jano

Hors ligne

#8 18/11/2020 0:36:59

jano
Moderateur
Inscription : 13/11/2007
Messages : 949

Re : vol en multiplayeurs, analyse et réglages (lag)

Vient-elle de mon PC portable ou de la carte graphique qui n'est manifestement pas optimale/suffisante pour FG?

boaf, pour la carte graphique, oin peut diminuer les options de rendu pour la rendre plus véloce, j'ai du mal au dessous des 20fps, et du coup avec mon vieux dual core je suis sans batiments sans arbres et des fois avec les nuages 2D et aussi avec un avion à faible charge (pas de nasal )

ceci dit oui un cpu chargé peut entrainer une dérive d'horloge, ça dépend un peu de ce qui sert de référence pour l'horloge, si c'est un oscillateur intégré, si c'est des cycles cpu etc...

mais maintenant que tu as le mode d'emploi, tu vas pouvoir tester tout ça en fonction des réglages, me souviens avoir signalé une dérive à un pilote avec qui je vole régulièrement, et il était en train de jouer avec les réglages d'horloge smile et il a fini par trouver le bon réglage, mais sa dérive était vraiment importante, toi avec tes 70ms / 2h calcules ta précision smile

jano

Hors ligne

#9 18/11/2020 13:38:31

inexel0853
Membre
Inscription : 10/10/2020
Messages : 28

Re : vol en multiplayeurs, analyse et réglages (lag)

Merci Jano

J'ai installé le ntp meinberg comme suggéré. Il m'a automatiquement corrigé l'heure affichée, d'une heure. J'avais remarqué que W10 me mettait régulièrement une heure en arrière bien que les paramètres heure et date soient synchronisés. Je faisait des rectifications manuelles dès détection. Je ne sais si cela pouvait expliquer mon problème.

Cordialement

Laurent


Windows 10, 64 bits, Intel Core i5-4310M CPU 2.70 Ghz RAM 4 Go Carte Graphique Intel HD Graphics 4600
FG 2020.1.1 - Thrustmaster T16000M / TWCS-Throttle  - Callsign: F-LCAS

Hors ligne

Pied de page des forums