Accueil
Accueil

Bienvenue invité ( Connexion | Inscription )

2 Pages V < 1 2  
Reply to this topicStart new topic
> [LOTATC] Au sujet des freezes
Ezor
post 19 May 2007, 20:26
Message #11




Co-Fondateur, webmaster

Indicatif : S-63
Messages : 3,013
Inscrit : 27/11/04
Lieu : Villers Allerand
Membre n° 2

CITATION(MajorBug @ 19 May 2007, 21:18) *

Sauf que la bande passante utilisée est pas exactement la même. Avec 40 clients qui pompent toute la bande passante c'est pas dit que l'export lua se sente à l'aise wink.gif

Dailleurs comment vous avez identifié où se situait le goulot avec lotatc ? (piti test ?)


On a testé pendant plus d'une heure en étudiant les trames entre les différentes parties.

Comme je l'ai déjà dis nous avons conclu que le problème vient du transfert de données entre le LOTATC Server et le LOTATC client.

LOTATC Server reçoit correctement toutes les informations, traite ces données et les réémet à tout les clients et c'est là que le bas blaisse. Les trames sortent de LOTATC Server mais disparaissent dans la nature une fois sur deux (voir systématiquement).

Le problème est plus d'ordre réseau donc, d'autant que nous avons pu reproduire le problème du LAN avec 100 clients IA (sans même un seul client humain).

On soupsonne la taille maximale des trames définis dans LOTATC être la source du problème. Ca passe correctement sur un réseau dit "lan" comme le VPN, ça passe pas du tout voir quasiement pas par le réseau internet classique et ça clignote en lan (ça on ne l'explique pas non plus).
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
MajorBug
post 19 May 2007, 21:28
Message #12




GЯЄЦН !

Indicatif : JR-11
Messages : 5,271
Inscrit : 25/10/05
Lieu : Rennes (35)
Membre n° 278

C'était même plus subtil que ça : c'était fluide pour certains et invivable pour d'autres ...

En tout cas bien vu pour les tests thumbsup.gif

--------------------
Image IPB

User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Lynx
post 19 May 2007, 22:29
Message #13






Indicatif : BS-05
Messages : 2,413
Inscrit : 23/03/05
Lieu : FONTENAY-SOUS-BOIS
Membre n° 108

Je plussoie fortement, ce sera certainement un point qui soulagera la vie de tout le monde... Pilotes comme contrôleurs... Sur le net ou en LAN, à tester le plus vite possible. gap.gif
Merci à vous deux. notworthy.gif

--------------------
3rdlynx.ddns.net

Serveur Discord Perso/Mission Editor : 965280400698146836

The agnostic dislexic insomniac: lies awake in bed at night wondering if there really is a dog.

T-IR 5, THRUSTMASTER WARTHOG +Virpil WAR BRD, Pilotseat GameRacer Pro, Oculus Rift S+ SIMSHAKER JETPAD(+ MFD's (démontés) )

Config
+ MSI 6950XT 340W
+ be quiet! Pure Rock 2
+ Mushkin Redline 64 Go 2 x 32 Go DDR4 3600 MHz
+ AMD Ryzen 7 5800X3D, 3,4 GHz (4,5 GHz Turbo Boost)
+ be quiet! Pure Power 11 FM 1000W,
+ SAMSUNG 980 PRO, 2 To, SSD
+ ASUS PRIME X570-P,
+ Sharkoon RGB LIT 100.

Image IPB

User is offlineProfile CardPM
Go to the top of the page
+Quote Post
HubMan
post 10 Aug 2007, 10:43
Message #14



 


Messages : 29
Inscrit : 27/07/07
Membre n° 2,120

CITATION(Ezor @ 19 May 2007, 22:26) *

On a testé pendant plus d'une heure en étudiant les trames entre les différentes parties.

Comme je l'ai déjà dis nous avons conclu que le problème vient du transfert de données entre le LOTATC Server et le LOTATC client.

LOTATC Server reçoit correctement toutes les informations, traite ces données et les réémet à tout les clients et c'est là que le bas blaisse. Les trames sortent de LOTATC Server mais disparaissent dans la nature une fois sur deux (voir systématiquement).

Le problème est plus d'ordre réseau donc, d'autant que nous avons pu reproduire le problème du LAN avec 100 clients IA (sans même un seul client humain).

On soupsonne la taille maximale des trames définis dans LOTATC être la source du problème. Ca passe correctement sur un réseau dit "lan" comme le VPN, ça passe pas du tout voir quasiement pas par le réseau internet classique et ça clignote en lan (ça on ne l'explique pas non plus).

Salut Ezor, salut Doug smile.gif petit déterrage de post : il y a de très fortes chances que les freeze viennent de là aussi : si je me souviens bien la taille maximale possible d'un datagramme Ip, c'est 65535 octets ie pour un message udp 65507 octets (on enlève la taille du header IP).

Le hic, c'est que c'est pas parce que la norme permet d'envoyer des paquets de bourrins en une seule fois que ça se passera bien derrière. Un paquet de 65Ko, c'est beaucoup trop gros pour beaucoup d'équipements réseaux.

Les PC, les routeurs etc... possèdent donc une taille limite de message, au dela de laquelle, le message sera fragmenté / découpé en morceaux (en trames IP), ça s'appelle la MTU (Maximum Transmission Unit). Le soucis, se trouve alors au niveau du réassemblage des bouts : il n'y aucun méchanisme qui assure au niveau IP que des paquets perdus seront redemandés (par contre, le désenquencement est géré). En conséquence, il suffit qu'un seul des petits paquets fragmenté soit perdu pour que le paquet complet soit perdu.

Et vu qu'UDP ne gère pas la perte de packets, contrairement à TCP, et que sur le net, la probabilité de perte de paquets fragmentés est très supérieure à celle d'un LAN, forcèment, ça coince et c'est lié à la façon d'écrire son code réseau : si la taille des messages est proportionnelle à la quantité d'info à véhiculer, il y a forcèment un moment où ça explose, indépendamment de la bande passante disponible smile.gif

La RFC 791 précise d'ailleurs bien qu'au dessus de 576 octets pour un datagramme IP, ça risque très fortement d'être le bazar et qu'il vaut mieux l'éviter.
En tenant compte des tailles de header etc... On peut dire que 512 octets de données pour un message UDP, c'est le maximum conseillé.

Vu que les sources sont paumées et que de toutes façon, LOTAC 2.0 est dans le pipe, ça n'a pas de sens de s'acharner là dessus, je dis surtout ça en pensant à vos devs actuels smile.gif , je ne sais pas comment vous allez vous y prendre à ce niveau là, mais il vaudrait surement mieux considérer que la compression ne réglerera pas forcèment ces problèmes et que si vous utilisez le protocole UDP qui est quand même beaucoup plus adapté à du flux que TCP, il vaudrait mieux véhiculer l'information d'entrée de jeu sous forme de petits messages de 512octets, parce que sinon, un jour ou l'autre, ça sautera pour un routeur plus restricitf que d'habitude qui n'aimera pas des paquets de 2ko smile.gif smile.gif


Ciao smile.gif

Hub.

PS : 512 octets, c'est -très- petit, c'est plus ou moins 0.5ko : un paquet de 20ko a de très fortes chances de se faire fragmenter et mettre le soukh, alors que ça n'a pas l'air si gros sur les standards actuels smile.gif
PPS : Le fait d'employer un VPN doit encapsuler le traffic UDP à travers un autre protocole et découper les gros messages UDP en petit messages VPN réassemblés proprement de l'autre coté... smile.gif

Ce message a été modifié par HubMan - 10 Aug 2007, 11:06.

--------------------
-
Image IPB
Image IPB
Image IPB
Image IPB
Image IPB

User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Doug
post 10 Aug 2007, 12:37
Message #15




Ladhouze pilot, eagle driver, amraams carrier, ...

Indicatif : F-01
Messages : 2,446
Inscrit : 27/11/04
Lieu : London
Membre n° 1

Oui, je pense utiliser UDP entre LockOn et le serveur LOTATC puis TCP entre les clients LOTATC et serveur LOTATC.

--------------------

User is offlineProfile CardPM
Go to the top of the page
+Quote Post

2 Pages V < 1 2
Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :
 

Haut de page · Retour à l'accueil · Contacter le Webmestre Nous sommes le : 28/03/24 - 14:24