abonnel-siteweb/data/pages/journal_geek/2012/10/31/connexions-adsl.txt

43 lines
4.1 KiB
Plaintext
Raw Permalink Normal View History

2024-01-07 10:02:35 +01:00
====== Connexion DSL ======
===== - Erreurs FEC - Erreur CRC =====
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éception((UIT-T / Recommandation G.992.1 (06/99), chapitre 7.6)). 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 ((http://forum.freenews.fr/index.php?topic=80354.0 il manque des explications sur cette valeur...))
Une ligne ne devrait pas dépasser 10 CRC/h ((référence ?)).
===== - Exemple d'informations relevées =====
^ ^ 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 |
{{page>vie_pratique:communication:historique_des_connexions_adsl:privee}}