l0g4n a écrit :
Et donc partir sur une techno qui ne garantie par l'absence de perte (ethernet, ou même IP), c'est adapté dans votre cas ?
|
Ivy gu a écrit :
Tant qu'il n'y a pas de lien surchargé il n'y a pas de perte, quand on contrôle les émetteurs et le réseau on peut garantir qu'il n'y aura pas de lien surchargé si on veut, le problème n'est pas là. Les algorithmes de gestion de la congestion ne sont utiles que parce que dans le cas général, une seule entité n'a pas le contrôle de bout en bout et donc chacun doit trouver des moyens de cohabiter et de résoudre les problèmes causés par le partage des ressources. Mais si on n'est pas dans ce cas, on n'a pas forcément besoin d'un algorithme pour résoudre la congestion, on peut s'arranger pour simplement qu'elle n'arrive pas.
|
Comment on maitrise le réseau (ceux qui envoient notamment) on peut potentiellement se passer d'algo de congestion qui sont assez gourmands en resources et surtout qui dit congestion dit paquets qui seront ralentis, or vu que nos flux de données sont des sortes de stream audio/vidéo, c'est pas possible. Donc on se débrouillera pour limiter la bande passante autour des 80%. Mais au niveau switch faut se débrouiller pour qu'il n'y ait pas de routage foireux qui viendrait congestionner un port.
C'est ce qui nous avait mis sur la piste des VLAN pour isoler les flux, mais avec du simple multicast et gestion d'IP/adresses mac, si on se goure pas sur les attributions d'IP ça devrait pas poser de problème. (On a 2 réseaux : un réseau pour les données et un réseau de contrôle pour venir contrôler les FPGA)
Et au niveau hardware (c'est mon taf), bah on s'arrange pour designer des liens qui n'entraîneront pas de perte (on va probablement rester sur un classique 10e-12 en terme de BER). On est pas sur des réseaux critiques.
Message édité par zeql_ le 10-11-2021 à 23:35:40