Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
Bon ! Pugnace, j'essaie depuis le bureau. - Mail original - De: "Michel Hostettler" À: "Michel Py" Cc: "stef" , "frnog" Envoyé: Lundi 22 Avril 2019 19:54:36 Objet: Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... Glurk !... L'accès à Michel Py a été rejeté "adresse IP blacklisté !". Peut-être pour cause de lundi de Pâques. J'essaierai demain, depuis le bureau. - Mail original - De: "Michel Hostettler" À: "Michel Py" Cc: "stef" , "frnog" Envoyé: Lundi 22 Avril 2019 19:45:39 Objet: Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... >> Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au >> débit de ligne. > Je ne vois pas la différence... Pourrais-tu, STP, te forcer doucement ?... Pour un débit source de 100 Gbit/s, transmis sur une seule longueur d'onde, un codage NRZ occuperait une bande passante de 200 GHz et, avec un codage plus évolué, une bande passante de 25 GHz (pour le même débit source, MAC). En fait, la bande passante de 200 GHz étant trop large, le codage NRZ est utilisé par l'IEEE pour une transmission sur 4 longueurs d'onde. Sinon, les codages évolués sont utilisés par l'UIT-T. Ceci n'est pas de la théorie, mais du concrete (béton en anglais). Cordialement, Michel (sans le point) - Mail original - De: "Michel Py" À: "Michel Hostettler" Cc: "stef" , "frnog" Envoyé: Dimanche 21 Avril 2019 05:04:04 Objet: RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... >> Michel Py a écrit : >> C'est là ou est le problème avec la fibre : on parlait >> dans le sujet d'une bande passante de plus de 100 G > Michel Hostettler a écrit : > Sapristi de sapristoche ! Michel-sans-le-point, considérant qu'être le troll autoproclamé de cette liste ne me donne pas le droit te parler pour ses membres, je te remercie néanmoins, toi qui vient d'un milieu disons plus académique, d'essayer de t'adapter au joyeux bordel de village gaulois que les ingénieurs de prod habitué(es) à la réalité brutale de la pratique sur le terrain ont tendance à préférer à la théorie. J'ai appris avec toi. Mais : > Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > débit de ligne. Je ne vois pas la différence. C'est comme la limite de la vitesse de la lumière, qu'elle soit dans la fibre, dans le vide, ou dans le Stroh. Il y a 10 ans, j'avais un Pentium à 3 GHz. Aujourd'hui, j'en ai un qui fait 5 GHz pendant quelques malheureuses secondes. Dans le domaine du WiFi, on a accepté aussi que le débit est une fonction finie du spectre qu'on utilise. Dans les 100 MHz de spectre qu'on a en 5.8, on peut mettre que x Gbps de bande passante (je laisse les spécialistes commenter). La fibre ce n'est pas différent : il y a 2 bandes, 1300 et 1550 (à la louche) et leur potentiel est limité. > Avec un codage de ligne 2D-QAM16, la transmission du débit de niveau 2 à 100 > Gbit/s > sur une longueur d'onde équivaut à peu près à celle du 10 Gbit/s en codage de > ligne NRZ. Aux dépends du rapport S/B. La bande passante, c'est comme le pognon : çà ne pousse pas sur les arbres. Dans le domaine du WiFi, on est déjà à la limite de ce que QAM peut faire. C'est clair qu'entre pas de QAM et ce qui devient banal aujourd'hui on a gagné beaucoup, mais la croissance est logarithmique. Entre ce qu'on a aujourd'hui en QAM1024 et ce qu'on peut éventuellement produire en 25 ans avec QAM.Million, on va péniblement doubler la bande passante. La fibre n'est pas différente que les ondes microwave. Dans x Hz de bande passante (ou de longueur d'onde, ce qui est la même chose) on ne peut passer que y bits avant que le rapport S/B de la liaison ne devienne un obstacle. J'ai dit et je recommence : FEC, c'est comme QOS : çà fait gagner 1 ou 2 ans avant de mettre un tuyau plus gros. Il y a 2 choses qui font tourner l'Internet : le cul, et le pognon. La FEC, c'est bien si çà se vend, et pas bien si çà ne se vend pas. Les cimetières sont remplis de gens indispensables. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
> La on doit bien rendrer dans la confusion "bps" vs "baud" a.k.a. > "symbole/sec", ou un symbole peut bien transporter plusieurs bits. Depuis longtemps, je n'utilise plus le terme de baud. Un symbole correspond à n bits, et sa durée suffit à le caractériser. La notion de baud est totalement inutile. > D'ailleurs meme en 10Gbps, le codage de ligne n'est pas du NRZ pur, mais du > 64b/66b. Sgoink ! Le codage de ligne est la transformation du numérique en un signal transmis sur la ligne, soit en électrique, soit en champ électromagnétique. Ne confondez pas le codage de ligne avec le codage de canal qui le précède, purement numérique. > En 100G, c'est du 64b/66b de base pour le 4x25 En codage de canal pour le 100GBase-ER4, exact. Dans le codage de canal entrent aussi le FEC (pas toujours optionnel), l'embrouillage... > 4bit/sym (cette version existe, j'ai plus en tete le produit, juste le > constructeur). QAM16 correspond à 4 bits par symbole, utilisé pour OTU4. Cordialement, Michel - Mail original - De: "Radu-Adrian Feurdean" À: "frnog" Envoyé: Mardi 23 Avril 2019 08:52:58 Objet: Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... On Mon, Apr 22, 2019, at 19:46, Michel Hostettler wrote: > > >> Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > >> débit de ligne. > > > Je ne vois pas la différence... > > Pourrais-tu, STP, te forcer doucement ?... > > Pour un débit source de 100 Gbit/s, transmis sur une seule longueur > d'onde, un codage NRZ occuperait une bande passante de 200 GHz et, avec > un codage plus évolué, une bande passante de 25 GHz (pour le même débit > source, MAC). > > En fait, la bande passante de 200 GHz étant trop large, le codage NRZ > est utilisé par l'IEEE pour une transmission sur 4 longueurs d'onde. > Sinon, les codages évolués sont utilisés par l'UIT-T. La on doit bien rendrer dans la confusion "bps" vs "baud" a.k.a. "symbole/sec", ou un symbole peut bien transporter plusieurs bits. D'ailleurs meme en 10Gbps, le codage de ligne n'est pas du NRZ pur, mais du 64b/66b. En 100G, c'est du 64b/66b de base pour le 4x25, mais pour les codages "avances", ca peut bien etre autre chose, par exemple 25 Gsym/sec, et 4bit/sym (cette version existe, j'ai plus en tete le produit, juste le constructeur). --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
On Mon, Apr 22, 2019, at 19:46, Michel Hostettler wrote: > > >> Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > >> débit de ligne. > > > Je ne vois pas la différence... > > Pourrais-tu, STP, te forcer doucement ?... > > Pour un débit source de 100 Gbit/s, transmis sur une seule longueur > d'onde, un codage NRZ occuperait une bande passante de 200 GHz et, avec > un codage plus évolué, une bande passante de 25 GHz (pour le même débit > source, MAC). > > En fait, la bande passante de 200 GHz étant trop large, le codage NRZ > est utilisé par l'IEEE pour une transmission sur 4 longueurs d'onde. > Sinon, les codages évolués sont utilisés par l'UIT-T. La on doit bien rendrer dans la confusion "bps" vs "baud" a.k.a. "symbole/sec", ou un symbole peut bien transporter plusieurs bits. D'ailleurs meme en 10Gbps, le codage de ligne n'est pas du NRZ pur, mais du 64b/66b. En 100G, c'est du 64b/66b de base pour le 4x25, mais pour les codages "avances", ca peut bien etre autre chose, par exemple 25 Gsym/sec, et 4bit/sym (cette version existe, j'ai plus en tete le produit, juste le constructeur). --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
>> Michel Py a écrit : >> Question de taux d'erreur : sur la fibre, le taux d'erreur acceptable est >> 10E-06, 1 sur 1 >> million. Contrairement à ce qu'en disent certains, l'absence de FEC n'est >> pas un problème. > Radu-Adrian Feurdean a écrit : > Tu n'as jamais vu des erreurs sur une fibre ? Ni meme en DWDM passif ? Moi > si, et (sans > blague) le taux depend plus du temps qu'il fait dehors plus qu'autre chose. > Deja eu ca > sur des troncons differents, operateurs differents, avec de optiques > differentes... C'est intéressant de voir comme on est d'accord sur QOS et pas d'accord sur FEC :P J'en ai vu oui, y compris sur une fibre de 4 km qui était tellement pourrie qu'on à du mettre des optiques 40 km parce que les optiques 10 km ne passaient pas. En interne, j'ai au moins 50% de ma fibre noire que ne marche pas bien (antique), il y a rien à comprendre, dans le même câble il y a des paires qui marchent et d'autres pas, t'as beau nettoyer et dire des gros mots et comparer au réflectromètre c'est comme pisser dans un violon. Ceci étant dit, il faut connaitre son réseau. La fibre qui commence à faire des erreurs quand on est sur que rien n'a changé physiquement, dans mon expérience c'est une optique qui meurt, pas la fibre. Les pelleteuses et les rats çà existe, mais çà fait généralement pas dans la dentelle. Mon avis : quand tu commences à avoir des erreurs et que changer les optiques, les jarretières, nettoyer et tout çà ne suffit pas, je préfère investir dans de la fibre noire de qualité. FEC c'est une solution d'attente quand tu n'as pas le choix. Tu peux être sur que ta fibre qui survit péniblement avec FEC ne vaut pas un caramel mou avec la prochaine génération d'optiques. Moi je préfère mettre le CAPEX dans quelque chose qui a de l'avenir. Bon c'est comme QOS : il y a des cas désespérés mais pas beaucoup. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
Glurk !... L'accès à Michel Py a été rejeté "adresse IP blacklisté !". Peut-être pour cause de lundi de Pâques. J'essaierai demain, depuis le bureau. - Mail original - De: "Michel Hostettler" À: "Michel Py" Cc: "stef" , "frnog" Envoyé: Lundi 22 Avril 2019 19:45:39 Objet: Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... >> Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au >> débit de ligne. > Je ne vois pas la différence... Pourrais-tu, STP, te forcer doucement ?... Pour un débit source de 100 Gbit/s, transmis sur une seule longueur d'onde, un codage NRZ occuperait une bande passante de 200 GHz et, avec un codage plus évolué, une bande passante de 25 GHz (pour le même débit source, MAC). En fait, la bande passante de 200 GHz étant trop large, le codage NRZ est utilisé par l'IEEE pour une transmission sur 4 longueurs d'onde. Sinon, les codages évolués sont utilisés par l'UIT-T. Ceci n'est pas de la théorie, mais du concrete (béton en anglais). Cordialement, Michel (sans le point) - Mail original - De: "Michel Py" À: "Michel Hostettler" Cc: "stef" , "frnog" Envoyé: Dimanche 21 Avril 2019 05:04:04 Objet: RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... >> Michel Py a écrit : >> C'est là ou est le problème avec la fibre : on parlait >> dans le sujet d'une bande passante de plus de 100 G > Michel Hostettler a écrit : > Sapristi de sapristoche ! Michel-sans-le-point, considérant qu'être le troll autoproclamé de cette liste ne me donne pas le droit te parler pour ses membres, je te remercie néanmoins, toi qui vient d'un milieu disons plus académique, d'essayer de t'adapter au joyeux bordel de village gaulois que les ingénieurs de prod habitué(es) à la réalité brutale de la pratique sur le terrain ont tendance à préférer à la théorie. J'ai appris avec toi. Mais : > Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > débit de ligne. Je ne vois pas la différence. C'est comme la limite de la vitesse de la lumière, qu'elle soit dans la fibre, dans le vide, ou dans le Stroh. Il y a 10 ans, j'avais un Pentium à 3 GHz. Aujourd'hui, j'en ai un qui fait 5 GHz pendant quelques malheureuses secondes. Dans le domaine du WiFi, on a accepté aussi que le débit est une fonction finie du spectre qu'on utilise. Dans les 100 MHz de spectre qu'on a en 5.8, on peut mettre que x Gbps de bande passante (je laisse les spécialistes commenter). La fibre ce n'est pas différent : il y a 2 bandes, 1300 et 1550 (à la louche) et leur potentiel est limité. > Avec un codage de ligne 2D-QAM16, la transmission du débit de niveau 2 à 100 > Gbit/s > sur une longueur d'onde équivaut à peu près à celle du 10 Gbit/s en codage de > ligne NRZ. Aux dépends du rapport S/B. La bande passante, c'est comme le pognon : çà ne pousse pas sur les arbres. Dans le domaine du WiFi, on est déjà à la limite de ce que QAM peut faire. C'est clair qu'entre pas de QAM et ce qui devient banal aujourd'hui on a gagné beaucoup, mais la croissance est logarithmique. Entre ce qu'on a aujourd'hui en QAM1024 et ce qu'on peut éventuellement produire en 25 ans avec QAM.Million, on va péniblement doubler la bande passante. La fibre n'est pas différente que les ondes microwave. Dans x Hz de bande passante (ou de longueur d'onde, ce qui est la même chose) on ne peut passer que y bits avant que le rapport S/B de la liaison ne devienne un obstacle. J'ai dit et je recommence : FEC, c'est comme QOS : çà fait gagner 1 ou 2 ans avant de mettre un tuyau plus gros. Il y a 2 choses qui font tourner l'Internet : le cul, et le pognon. La FEC, c'est bien si çà se vend, et pas bien si çà ne se vend pas. Les cimetières sont remplis de gens indispensables. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
>> Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au >> débit de ligne. > Je ne vois pas la différence... Pourrais-tu, STP, te forcer doucement ?... Pour un débit source de 100 Gbit/s, transmis sur une seule longueur d'onde, un codage NRZ occuperait une bande passante de 200 GHz et, avec un codage plus évolué, une bande passante de 25 GHz (pour le même débit source, MAC). En fait, la bande passante de 200 GHz étant trop large, le codage NRZ est utilisé par l'IEEE pour une transmission sur 4 longueurs d'onde. Sinon, les codages évolués sont utilisés par l'UIT-T. Ceci n'est pas de la théorie, mais du concrete (béton en anglais). Cordialement, Michel (sans le point) - Mail original - De: "Michel Py" À: "Michel Hostettler" Cc: "stef" , "frnog" Envoyé: Dimanche 21 Avril 2019 05:04:04 Objet: RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... >> Michel Py a écrit : >> C'est là ou est le problème avec la fibre : on parlait >> dans le sujet d'une bande passante de plus de 100 G > Michel Hostettler a écrit : > Sapristi de sapristoche ! Michel-sans-le-point, considérant qu'être le troll autoproclamé de cette liste ne me donne pas le droit te parler pour ses membres, je te remercie néanmoins, toi qui vient d'un milieu disons plus académique, d'essayer de t'adapter au joyeux bordel de village gaulois que les ingénieurs de prod habitué(es) à la réalité brutale de la pratique sur le terrain ont tendance à préférer à la théorie. J'ai appris avec toi. Mais : > Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > débit de ligne. Je ne vois pas la différence. C'est comme la limite de la vitesse de la lumière, qu'elle soit dans la fibre, dans le vide, ou dans le Stroh. Il y a 10 ans, j'avais un Pentium à 3 GHz. Aujourd'hui, j'en ai un qui fait 5 GHz pendant quelques malheureuses secondes. Dans le domaine du WiFi, on a accepté aussi que le débit est une fonction finie du spectre qu'on utilise. Dans les 100 MHz de spectre qu'on a en 5.8, on peut mettre que x Gbps de bande passante (je laisse les spécialistes commenter). La fibre ce n'est pas différent : il y a 2 bandes, 1300 et 1550 (à la louche) et leur potentiel est limité. > Avec un codage de ligne 2D-QAM16, la transmission du débit de niveau 2 à 100 > Gbit/s > sur une longueur d'onde équivaut à peu près à celle du 10 Gbit/s en codage de > ligne NRZ. Aux dépends du rapport S/B. La bande passante, c'est comme le pognon : çà ne pousse pas sur les arbres. Dans le domaine du WiFi, on est déjà à la limite de ce que QAM peut faire. C'est clair qu'entre pas de QAM et ce qui devient banal aujourd'hui on a gagné beaucoup, mais la croissance est logarithmique. Entre ce qu'on a aujourd'hui en QAM1024 et ce qu'on peut éventuellement produire en 25 ans avec QAM.Million, on va péniblement doubler la bande passante. La fibre n'est pas différente que les ondes microwave. Dans x Hz de bande passante (ou de longueur d'onde, ce qui est la même chose) on ne peut passer que y bits avant que le rapport S/B de la liaison ne devienne un obstacle. J'ai dit et je recommence : FEC, c'est comme QOS : çà fait gagner 1 ou 2 ans avant de mettre un tuyau plus gros. Il y a 2 choses qui font tourner l'Internet : le cul, et le pognon. La FEC, c'est bien si çà se vend, et pas bien si çà ne se vend pas. Les cimetières sont remplis de gens indispensables. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
On Sat, Apr 20, 2019, at 19:09, Michel Py wrote: > Pas en xWDM. Si on veut faire de la FEC dans ce contexte, c'est bien > plus simple de la faire sur chaque canal individuellement que de la > faire sur la ligne. > > Question de taux d'erreur : sur la fibre, le taux d'erreur acceptable > est 10E-06, 1 sur 1 million. > Contrairement à ce qu'en disent certains, l'absence de FEC n'est pas un > problème. Tu n'as jamais vu des erreurs sur une fibre ? Ni meme en DWDM passif ? Moi si, et (sans blague) le taux depend plus du temps qu'il fait dehors plus qu'autre chose. Deja eu ca sur des troncons differents, operateurs differents, avec de optiques differentes... --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
>> Michel Py a écrit : >> C'est là ou est le problème avec la fibre : on parlait >> dans le sujet d'une bande passante de plus de 100 G > Michel Hostettler a écrit : > Sapristi de sapristoche ! Michel-sans-le-point, considérant qu'être le troll autoproclamé de cette liste ne me donne pas le droit te parler pour ses membres, je te remercie néanmoins, toi qui vient d'un milieu disons plus académique, d'essayer de t'adapter au joyeux bordel de village gaulois que les ingénieurs de prod habitué(es) à la réalité brutale de la pratique sur le terrain ont tendance à préférer à la théorie. J'ai appris avec toi. Mais : > Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au > débit de ligne. Je ne vois pas la différence. C'est comme la limite de la vitesse de la lumière, qu'elle soit dans la fibre, dans le vide, ou dans le Stroh. Il y a 10 ans, j'avais un Pentium à 3 GHz. Aujourd'hui, j'en ai un qui fait 5 GHz pendant quelques malheureuses secondes. Dans le domaine du WiFi, on a accepté aussi que le débit est une fonction finie du spectre qu'on utilise. Dans les 100 MHz de spectre qu'on a en 5.8, on peut mettre que x Gbps de bande passante (je laisse les spécialistes commenter). La fibre ce n'est pas différent : il y a 2 bandes, 1300 et 1550 (à la louche) et leur potentiel est limité. > Avec un codage de ligne 2D-QAM16, la transmission du débit de niveau 2 à 100 > Gbit/s > sur une longueur d'onde équivaut à peu près à celle du 10 Gbit/s en codage de > ligne NRZ. Aux dépends du rapport S/B. La bande passante, c'est comme le pognon : çà ne pousse pas sur les arbres. Dans le domaine du WiFi, on est déjà à la limite de ce que QAM peut faire. C'est clair qu'entre pas de QAM et ce qui devient banal aujourd'hui on a gagné beaucoup, mais la croissance est logarithmique. Entre ce qu'on a aujourd'hui en QAM1024 et ce qu'on peut éventuellement produire en 25 ans avec QAM.Million, on va péniblement doubler la bande passante. La fibre n'est pas différente que les ondes microwave. Dans x Hz de bande passante (ou de longueur d'onde, ce qui est la même chose) on ne peut passer que y bits avant que le rapport S/B de la liaison ne devienne un obstacle. J'ai dit et je recommence : FEC, c'est comme QOS : çà fait gagner 1 ou 2 ans avant de mettre un tuyau plus gros. Il y a 2 choses qui font tourner l'Internet : le cul, et le pognon. La FEC, c'est bien si çà se vend, et pas bien si çà ne se vend pas. Les cimetières sont remplis de gens indispensables. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
> C'est là ou est le problème avec la fibre : on parlait dans le sujet d'une > bande passante de plus de 100 G Sapristi de sapristoche ! Vous n'allez pas croire que le débit du niveau 2 (100 Gbit/s) équivaut au débit de ligne. Avec un codage de ligne 2D-QAM16, la transmission du débit de niveau 2 à 100 Gbit/s sur une longueur d'onde équivaut à peu près à celle du 10 Gbit/s en codage de ligne NRZ. Cordialement, Michel - Mail original - De: "Michel Py" À: "stef" , "frnog" Envoyé: Samedi 20 Avril 2019 19:07:54 Objet: RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ... > Stéphane Rivière a écrit : > Me permets ces remarques pour remettre le FEC dans > son contexte général (canaux fortement perturbés), La partie "fortement perturbé" n'est pas valable pour la fibre, voir plus bas. Pour la radio, je ne me pose même pas la question. Ce qui suit est pour Ubiquiti, et la FEC fait partie de la modulation QAM, et c'est très bien. Pareil pour la mémoire ECC ou les disques durs en RAID, ne pas le faire c'est idiot car le cout supplémentaire va payer à la première panne. C'est comme les alims redondantes ou les onduleurs, ce n'est pas une option. > Le FEC aura un temps de traitement qui n'impactera pas le débit garanti. > Mes remarques sont indépendantes de la vitesse. C'est là ou est le problème avec la fibre : on parlait dans le sujet d'une bande passante de plus de 100 G, le matériel pour faire de la FEC line-rate à cette vitesse est d'un cout prohibitif, si même il existe. > C'est justement au niveau de la ligne qu'on l'y colle :) > Après, ça voudrait dire que le code perd des bits... Pas en xWDM. Si on veut faire de la FEC dans ce contexte, c'est bien plus simple de la faire sur chaque canal individuellement que de la faire sur la ligne. Question de taux d'erreur : sur la fibre, le taux d'erreur acceptable est 10E-06, 1 sur 1 million. Contrairement à ce qu'en disent certains, l'absence de FEC n'est pas un problème. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
> Stéphane Rivière a écrit : > Me permets ces remarques pour remettre le FEC dans > son contexte général (canaux fortement perturbés), La partie "fortement perturbé" n'est pas valable pour la fibre, voir plus bas. Pour la radio, je ne me pose même pas la question. Ce qui suit est pour Ubiquiti, et la FEC fait partie de la modulation QAM, et c'est très bien. Pareil pour la mémoire ECC ou les disques durs en RAID, ne pas le faire c'est idiot car le cout supplémentaire va payer à la première panne. C'est comme les alims redondantes ou les onduleurs, ce n'est pas une option. > Le FEC aura un temps de traitement qui n'impactera pas le débit garanti. > Mes remarques sont indépendantes de la vitesse. C'est là ou est le problème avec la fibre : on parlait dans le sujet d'une bande passante de plus de 100 G, le matériel pour faire de la FEC line-rate à cette vitesse est d'un cout prohibitif, si même il existe. > C'est justement au niveau de la ligne qu'on l'y colle :) > Après, ça voudrait dire que le code perd des bits... Pas en xWDM. Si on veut faire de la FEC dans ce contexte, c'est bien plus simple de la faire sur chaque canal individuellement que de la faire sur la ligne. Question de taux d'erreur : sur la fibre, le taux d'erreur acceptable est 10E-06, 1 sur 1 million. Contrairement à ce qu'en disent certains, l'absence de FEC n'est pas un problème. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
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/
[FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...
Petit historique pour les jeunes : La détection d'erreurs, çà a commence avec le bit de parité. Pour les liens série : parité ou pas. 7 ou 8 bits de données, 0 ou 1 bit de parité. C'est une simple somme de contrôle. Il n'y a rien à faire en cas d'erreur : on ne peut pas savoir lequel des bits a une erreur, seulement qu'on a une erreur. Pour la mémoire : similaire. Sans parité : 8 bits. Avec parité : 9 bits. Si erreur : NMI, BSOD. Un peu plus évolué, la mémoire ECC : 8 bits de données, 3 de parité. Cette mémoire peut corriger 1 bit d'erreur. But : non pas de corriger les erreurs en permanence, mais de faire savoir à l'admin que la mémoire est en train de mourir, çà fait donc gagner un peu de temps en laissant le système fonctionner mais le seul remède c'est de changer la mémoire défectueuse. Les admins qui ignorent les corrections ECC vont bientôt se retrouver dans le même cas d'une erreur de parité : plus qu'un bit d'erreur, BSOD. Un peu plus tard, le RAID5. Même idée, plus de bits que les données à stocker, un disque de plus qu'il est nécessaire. Si un disque dur meurt, remplacer le disque dur. Là encore, la détection et la correction de l'erreur ne sont qu'un moyen de gagner du temps pour résoudre le défaut. Le RAID avec un disque en panne continue à marcher, mais si on ne remplace pas rapidement le disque et qu'on ne reconstruit pas les données, le jour ou un second disque meurt on a tout perdu. Et maintenant, FEC. La même idée : on transmet plus de bits que nécessaire, si le nombre de bits en erreur est inférieur à ce que permet le système, on peut corriger la trame. 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. En plus, FEC ce n'est pas transparent en terme de latence. Pourquoi : - On transmet plus de bits que nécessaire. - A part la transmission, il faut analyser à l'arrivée si l'information est cohérente, ce qui prend du temps. 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. - 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. Faut pas oublier que pendant que tout ce business de FEC prend place, les paquets continuent à arriver à n x 10G, ou pire. FEC n'enlève pas les erreur. 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. Le FEC sur la ligne, c'est pas là ou j'en ai besoin. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
