Le 19/04/2019 à 20:35, Michel Py a écrit :
Petit historique pour les jeunes :
La fibre n'est pas un milieu que je connais du tout (quoique je me forme, merci David entre autres) mais le FEC si.
Me permets ces remarques pour remettre le FEC dans son contexte général (canaux fortement perturbés), hein, pas pour te chambrer, le FEC pour la fibre est certainement un domaine plus dispensable qu'en radio.
Pourquoi j'en ai pas besoin : - Si c'est de la voix ou de la vidéo en UDP, et que j'ai 1E-08 de perte, je m'en fous. - Si c'est des données TCP et que j'ai 1E-08 de retransmissions, je m'en fous.
Puisqu'un FEC va généralement bouffer 30 à 50% de la BP... Il n'est pas utile d'en coller un sur une liaison avec un taux d'erreur acceptable pour l'application considérée. On est bien d'accord.
- A part la transmission, il faut analyser à l'arrivée si l'information est cohérente, ce qui prend du temps.
Ce sera transparent sinon la voip ou la video ne suivraient pas.
Au contraire d'un système RAID, il n'y a pas de signe clair que le disque ou le secteur est mort. Les bits arrivent, est-ce qu'il y a une erreur dedans ou non il faut exécuter l'algorithme de contrôle pour savoir, ce qui prend du temps.
Le FEC aura un temps de traitement qui n'impactera pas le débit garanti.
- Si il y a une erreur, c'est encore pire : l'algorithme de reconstruction est parfois plus compliqué que l'algorithme de détection, donc il va y avoir une forte latence avant que la trame corrigée arrive à destination.
Si l'on est dans le TR (temps-réel), la reconstruction est TR, sinon on perd la trame suivante avant d'avoir pu la traiter.
Faut pas oublier que pendant que tout ce business de FEC prend place, les paquets continuent à arriver à n x 10G, ou pire.
Mes remarques sont indépendantes de la vitesse.
FEC n'enlève pas les erreur.
C'est la fonction même du FEC. Au prix d'un overhead non négligeable, il remonte le bilan de liaison (le gain peut s'exprimer en dB) à un niveau qui est l'objectif de performance pour l'application (cet objectif pouvant être faible, élevé en fonction du canal, c'est pas le sujet).
Plus précisément, il corrige certaines erreurs, dans les limites de sa conception et des défauts spécifiques du canal. Les défauts spécifiques d'un canal radio (mon domaine) ne sont pas nécessairement ceux d'un canal fibre (pas mon domaine).
Cà essaie de donner l'illusion qu'il n'y en a pas, ce qui est une solution d'attente à court-terme. Et contrairement à la mémoire ou au disque dur en panne, les données ne sont pas perdues : elle peuvent être retransmises.
Dans le cas d'une communication vocale, les données sont évidemment perdues. D'où l'intérêt primordial du FEC, sans lequel un taux d'erreur élevé rendrait caduque la solution.
Le FEC est (je ne sais pas pour la fibre, c'est pas mon domaine) indispensable pour toute transmission d'un flux TR sur un canal fortement aléatoire (ce que n'est certainement pas une fibre, sauf en limite de portée garantie)
Et dans ce cas, ce n'est pas une solution d'attente à court terme mais une condition préalable à la mise en œuvre de la technologie (au hasard 2/3/4/5G mais pas que, loin de là).
Le FEC sur la ligne, c'est pas là ou j'en ai besoin.
C'est justement au niveau de la ligne qu'on l'y colle :) Après, ça voudrait dire que le code perd des bits... --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
