Décrire les sigles ! moduler la voix, faire des pauses sinon on décroche. UDP est simple mais moins fiable Chromium : ne pas confondre avec ChromiumBSU ! === dire où est - l'utilisateur (oeil) - carte graphique - PC puissant tilesort : exploiter un mur d'écran % % Utilisation normale d'OpenGL: une seule machine % \includegraphics{opengl_normal} === % % Chromium simple: packer % \includegraphics{chromium_packer} === % % Chromium plus évolué: tilesort % exploiter un mur d'écrans % \includegraphics{chromium_tilesort} === % % Les modifications que j'ai apporté % * IPv6 * UDP/TCP au lieu de TCP * découverte de MTU et adaptation automatique des buffers buffering : rebuffer, le dire ! === % % TCP vs UDP} % TCP fiable, car retransmet les données au besoin\\ mais délai pour attendre la retransmission UDP non fiable: se contente d'envoyer les données\\ mais utilise ainsi au maximum le media On voudrait utiliser UDP pour ses performances, malgré sa non-fiabilité % % premiers essais avec que UDP avapa % === % % où l'on explique comment synchroniser les deux canaux % UDP/TCP Seule la "géométrie" passe par UDP: de 80 à 99\% du traffic. Synchronisation avec le reste du traffic: \includegraphics{udp_tcp} === % % si on fait ça sans réfléchir : % \includegraphics[width=800pt]{croco-joli} === \includegraphics[width=800pt]{croco-beurk-beurk} === % % explication % \includegraphics{vertex_loss0} === \includegraphics{vertex_loss} === \includegraphics{vertex_loss1} === \includegraphics{vertex_lost} === \includegraphics{vertex_loss2} === \includegraphics{vertex_lost2} === \includegraphics{vertex_loss3} ce n'est qu'un des problèmes === % % résultat : % \includegraphics[width=800pt]{croco-beurk2} === % % résultats performance : % \includegraphics[height=590pt]{anneaux} === \includegraphics{chromium} % % % === {\Large 100Mbps :} Anneaux : * la synchronisation se fait en TCP * très peu de géométrie === {\Large 10Mbps :} === {\Large Wireless :} (typiquement 200Ko/s sur un transfert TCP) * gros gain car TCP doit retransmettre beaucoup * mais résultat déplorable en UDP à cause des nombreuses pertes === % % Bilan MITIGÉ ! % UDP/TCP est * adapté * si la géométrie est la plupart du traffic * si l'on ne se soucie pas trop de la qualité de rendu * si c'est animé (l'oeil compense) * s'il y a des pertes * si le réseau est le goulet d'étranglement * peu adapté * s'il faut une synchronisation des applications * si le réseau est beaucoup plus rapide que les machines === % % Et encore ?... % * utiliser sendmsg et recvmsg * utiliser multicast * tester sur VTHD (pas disponible à l'époque) * contrôler le flux * compression type MPEG