journal_geek:2012:10:31:connexions-adsl

Connexion DSL

Les données redondantes transmises au sein de chaque trame ADSL permettent de détecter et, dans une certaine mesure, de corriger les erreurs de réception1). Si l'erreur n'affecte que quelques bits dans la trame ADSL reçue, un mécanisme de correction d'erreur (forward error correction) incorporé au circuit de réception est en général capable de reconstruire les données abîmées. L'erreur est signalée dans les statistiques de réception sous la forme d'une « erreur FEC ». En revanche, si les données sont trop abîmées pour pouvoir être reconstituées, l'erreur est signalée sous la forme d'une « erreur CRC ». Dans certains cas, une erreur CRC affecte l'en-tête d'une cellule ATM, et cette altération est détectée par le récepteur, qui la signale sous la forme d'une « erreur HEC ». Enfin, si le taux d'erreur est suffisamment grand, la structure de la trame ADSL elle-même peut être affectée au point que plus aucune donnée reçue n'est utilisable. On constate alors une perte de tramage (« erreur LOF ») qui peut aller jusqu'à la perte totale de synchronisation (« erreur LOS »). En présence de ce type d'erreur, le modem ADSL réagit le plus souvent en interrompant la communication et en entamant une nouvelle procédure de synchronisation depuis le début. C'est le phénomène connu sous le nom de « désynchronisation » par les internautes.

Le protocole ATM ne supporte pas nativement de système de correction des erreurs. Quand se produit une erreur suffisamment sévère pour que le dispositif de correction d'erreur natif de l'ADSL (FEC) ne puisse pas la corriger, c'est-à-dire une erreur de type CRC, les cellules ATM affectées par l'erreur sont supprimées en réception. Il manque donc un segment dans les données utilisateur reçues par le destinataire. En général, une couche de protocole de niveau supérieur (TCP par exemple) fait le nécessaire pour demander la retransmission de ce segment manquant..

http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line#Gestion_des_erreurs_de_transmission

Une ligne ne devrait pas dépasser 500 FEC/s 2)

Une ligne ne devrait pas dépasser 10 CRC/h 3).

Temps de disponibilité Type DSL Bande passante (montante/descendante) Données transférées (envoyées/reçues)
2012/10/20 00:00 1 jour, 2:47:22 ITU-T G.992.1 800 / 5.600 301,32 MB / 1,99 GB
2012/10/28 17:10 0 jour, 8:17:45 ITU-T G.992.1 800 / 6.720 344,64 MB / 1,85 GB
2012/10/31 20:00 2 jours, 23:12:34 ITU-T G.992.1 800 / 5.792 1,07 GB / 1,99 GB
(montant/descendant) [dBm] Puissance de sortie Atténuation de ligne Marge signal/bruit
2012/10/20 00:00 12,3 / 19,8 23,5 / 44,5 19,0 / 10,4
2012/10/28 17:10 12,3 / 19,8 23,5 / 45,0 18,0 / 9,7
2012/10/31 20:00 12,3 / 19,8 23,5 / 44,5 19,0 / 10,0
(local/distant) Système ID fournisseur Chipset ID fournisseur Perte de trames Perte de signal Perte de puissance Perte de liaison (distant) Secondes d'erreurs
2012/10/20 00:00 TMMB / —- BDCM / BDCM 0 / - 0 / - 0 / - - 66 / -
2012/10/28 17:10 TMMB / —- BDCM / BDCM 0 / - 0 / - 0 / - - 13 / -
2012/10/31 20:00 TMMB / —- BDCM / BDCM 0 / - 0 / - 0 / - - 880 / -
(montant/descendant) Erreurs FEC FEC/s Erreurs CRC CRC/h Erreurs HEC
2012/10/20 00:00 0 / 2.518.060 25 0 / 151 - / 5,3 - / 142
2012/10/28 17:10 0 / 1.172.933 40 0 / 23 - / 2,3 - / 19
2012/10/31 20:00 0 / 8.704.560 34 0 / 173 - / 2,3 - / 163

1)
UIT-T / Recommandation G.992.1 (06/99), chapitre 7.6
2)
http://forum.freenews.fr/index.php?topic=80354.0 il manque des explications sur cette valeur…
3)
référence ?
  • journal_geek/2012/10/31/connexions-adsl.txt
  • Dernière modification : 2020/04/28 01:01
  • de jside