[info] Interprétation Informations Techniques

Voici quelques explications sur les termes barbares que l’on retrouve dans les informations techniques relatives à une ligne Free (en dégroupé) accessibles là :

http://adsl.free.fr/suivi/suivi_tech.html

Ces explications peuvent vous servir à déterminer notamment si vous avez une bonne ligne ou pas.

« Spurious atu detected » :

Normalement, le chiffre qui suit est à 0.

Il s’agit d’un « compteur de tentatives infructueuses de connexions ».
Le DSLAM a vu que quelque chose (votre Freebox) a essayé de se connecter à lui, mais sans succès.

Cela peut arriver en temps normal et si vous arrivez à vous connecter malgré tout, vous pouvez ignorer ce fait.

Si en revanche, vous n’arrivez pas du tout à vous connecter, il va falloir chercher la cause :
ce peut être la ligne FT (un mauvais cablage au niveau du DSLAM (très fréquemment à l’origine de ce problème), un mauvais branchement dans une prise, un filtre ADSL défectueux, etc.)

« Protocol Error »:

Normalement, ce chiffre est à 0.

En général, s’il est différent de zéro, le « Spurious ATU detected » est lui aussi supérieur à 0, se reporter au paragraphe ci dessus pour les causes possibles.

« Attainable bitrate » :

Il s’agit du débit maximum que peut atteindre votre Freebox sur votre ligne.
Si Free ne bridait pas à 7168 Kilo-bits/s, vous pourriez espérer atteindre la vitesse indiquée.
(pour ceux qui ont un « Attainable bitrate » supérieur à 7168 bien sûr, pour les autres vous avez déjà atteint le maximum que peut obtenir votre Freebox de votre ligne)

En mode « PATATE » on peut aller jusqu’à 7616 Kilo-bits/s ATM si le Attainable bitrate est au moins égal à 7616 et 800 Kilo-bits/s ATM en upload.

D’après un message de Rani Rassaf (responsable technique chez Free)
le mode Patate pourrait permettre d’aller jusqu’à 10240 / 800 (débits ATM)

A l’heure actuelle ( 26/09/2004) une poignée de personnes ont un « Attainable bitrate » supérieur à 8192 et/ou un « Chan data interleave » supérieur à 7616.

Pour le moment on ne peut que spéculer sur ce fait. Les semaines qui viennent
devrait nous permettre d’en savoir plus.

Le « Attainable bitrate » est généralement supérieur au « Chan data interleave » (débit réel), parfois égal, ce qui signifie que vous avez atteint la vitesse maximum que peut atteindre votre Freebox sur votre ligne.

Parfois on voit même un « Attainable bitrate » inférieur au « Chan data interleave » .

Le « Chan data interleave » est déterminé lors de la synchronisation de la Freebox avec le DSLAM alors que le « Attainable bitrate » semble être recalculé périodiquement (toutes les 24h) et si les conditions de ligne se déteriorent, alors on peut aboutir à cette situation paradoxale.

« Capacity occupation »:

Il s’agit du pourcentage d’occupation de votre ligne. C’est le ratio entre votre débit théorique (« Attainable bitrate ») et votre débit réel (« Chan data interleave »).

Par exemple Si vous avez 100 cela veut dire que vous avez atteint (réellement) le débit maximum de votre ligne.

Si vous avez 68 cela veut dire que vous utilisez 68 % de votre maximum théorique (5632 sur 7616 par exemple)

Ce chiffre n’est pas forcément significatif :

Attainable bitrate____: 6000 7000 7500
Chan data interleave_: 5632 5632 5632
Capacity occupation__:_94%_80%_75%

On pourrait se dire que la première ligne est moins bonne que les autres, (attainable bitrate plus faible) mais finalement, ce qui compte c’est le débit réel obtenu (« Chan data interleave ») et là on voit qu’il est identique dans les trois cas ci-dessus.

A l’inverse :

Attainable bitrate____: 7500 5000
Chan data interleave_: 5632 4000
Capacity occupation__:_75%_80%

Il faut mieux atteindre 75% d’une bonne ligne que 80% d’une moins bonne !

« Chan data Interleave » :
« Chan data Fastpath » :

(l’un ou l’autre selon que vous avez activé le mode FastPath ou que vous êtes en mode Interleave)

Là il s’agit de votre vrai débit, négocié par votre Freebox avec le DSLAM lors de votre connexion.

Les chiffres maximums d’une Freebox sont pour l’instant en mode Interleave :

Chan data Interleave : 7168 (far) 640 (near)

En mode PATATE on peut aller jusqu’à :

Chan data Interleave : 7616 (far) 800 (near)

(parfois plus, mais à l’heure actuelle (26/09/2004) c’est très rare, relire plus haut)

Attention, ces débits sont exprimés en Kilo-bits/s en ATM !

L’ATM est le protocole de transport des données utilisées par Free jusqu’à la Freebox. Mais l’ordinateur relié à la Freebox discute en TCP/IP. L’ATM agit comme une surcouche de TCP/IP.
On dit également que les paquets ATM encapsulent les paquets TCP/IP.

Pour convertir un débit exprimé en ATM en un débit exprimé en TCP/IP il faut grosso-modo diviser par 1.2 :

7168 Kilo-bits/s (ATM) / 1.2 = ~ 6000 Kilo-bits/s (en TCP/IP)
6000 Kilo-bits/s / 8 = ~ 750 Kilo-octets/s

7616 Kilo-bits/s (ATM) / 1.2 = ~ 6500 Kilo-bits/s (en TCP/IP)
6500 Kilo-bits/s / 8 = ~ 813 Kilo-octets/s

Pour la partie upload :

640 Kilo-bits/s (ATM) / 1.2 = ~533 Kilo-bits/s (TCP/IP)
533 Kilo-bits/s / 8 = ~ 66 Kilo-octets/s (TCP/IP)

800 Kilo-bits/s (ATM) / 1.2 = ~666 Kilo-bits/s (TCP/IP)
666 Kilo-bits/s / 8 = ~ 83 Kilo-octets/s (TCP/IP)

Il faut garder à l’esprit que ces chiffres sont des maximums, des vitesse de pointe. Il sera bien rare que vous puissiez aller longtemps (plusieurs heures) à ces vitesses là. Cela va dépendre de nombreux facteurs : l’encombrement global du réseau, l’encombrement du serveur sur lequel vous êtes connecté, etc.

Petit tableau d’exemples (arrondis pour simplifier) :

ATM TCP/IP Débit

7616 6500 813 Kilo-octets/s
7168 6000 750 Kilo-octets/s
5632 4700 585 Kilo-octets/s
4800 4000 500 Kilo-octets/s
4200 3500 438 Kilo-octets/s
3600 3000 375 Kilo-octets/s
3000 2500 313 Kilo-octets/s
2400 2000 250 Kilo-octets/s
1800 1500 188 Kilo-octets/s
1200 1000 125 Kilo-octets/s

Certains voient parfois des vitesses de téléchargement encore supérieures.

Très souvent il s’agit d’erreurs ou d’approximations dans le calcul de la vitesse effectué par le logiciel (client web, client FTP)

Parfois les logiciels utilisent des techniques de compression à la volée des données, ce qui peut aussi fausser le résultat.

Il faut bien comprendre qu’il n’y a pas de mesure absolue de la vitesse de téléchargement.
Comment en effet compter le nombre d’octets reçus dans un laps de temps donné ?
Cela peut paraître simple mais dans le détail :

Doit-on compter comme « arrivé » un paquet :

– arrivé dans la pile TCP/IP de la machine ?
– arrivé dans le premier buffer de l’application ?
– arrivé dans le dernier buffer de l’application ?
– stocké dans le disque dur ?

Sans évoquer les étapes intermédiaires ou des conditions particulières : l’utilisation d’un cache disque qui accélère le stockage sur disque dur par exemple.

Selon la méthode utilisée pour compter, on n’obtiendra pas le même résultat, donc d’un logiciel à un autre …

Sur une machine moderne toutes ces étapes ne représentent que quelques milli-secondes d’écart mais cela suffit à fausser un calcul de vitesse.

Par ailleurs, les auteurs de logiciels client web ou FTP ont intérêt, surtout pour les logiciels commerciaux, à être « optimistes » quant aux vitesses de download. En effet, c’est l’un des principaux critères de choix des internautes (« avec le client FTP xyz je télécharge à telle vitesse alors qu’avec le logiciel FTP abc je suis à 2 Ko/s moins vite »)

Avez-vous déjà mesuré, chrono en main, que votre client FTP vous dit la vérité ?

« Attenuation »:

Nombre ô combien important !

Il y a deux nombres, un pour l’upload (« up ») un pour le download (« down »)
Généralement vous serez surtout concerné par le chiffre pour le download.

Plus de chiffre est élevé, moins bonne sera votre connexion.

Généralement ce chiffre est lié à la distance (mais pas uniquement)
Plus vous êtes loin du DSLAM, plus votre atténuation risque d’être importante.

Grosso modo, c’est comme si vous deviez écouter quelqu’un parler : plus il est loin de vous, plus sa voix devient difficile à entendre, elle est atténuée.

En plus de la distance, ce qui compte c’est le diamètre des cables utilisés pour faire votre ligne.
Plus ils sont gros, meilleure sera votre connexion.

Il vaut mieux également avoir une ligne d’un seul tronçon, plutôt que plusieurs reliés entre eux.
Chaque point de jonction va augmenter votre atténuation.

C’est ce qui explique qu’à distance égale on constate parfois de grosses différences d’atténuations d’un internaute à un autre. Et on ne peut rien y faire puisque c’est la ligne FT.

Il y a un rapport théorique et approximatif de 69 entre la distance et l’atténuation :

700 m => 700 / 69 = ~ 7 db
1000 m => 1000 / 69 = ~ 14 db
1500 m => 1500 / 69 = ~ 22 db
2500 m => 2500 / 69 = ~ 36 db
3000 m => 3000 / 69 = ~ 43 db
4000 m => 4000 / 69 = ~ 58 db
5000 m => 5000 / 69 = ~ 72 db
6000 m => 6000 / 69 = ~ 87 db

Au dela de 3500 m ces chiffres s’éloignent parfois beaucoup de la réalité.
Dans la pratique on rencontre rarement des atténuations supérieures à 65 db.

Arbitrairement on peut dire qu’en dessous de 35 db vous avez une bonne ligne,
au dela de 55 db, la vitesse obtenue va s’en ressentir grandement.

Cela n’est pas forcément dramatique, il y a des gens avec de fortes atténuations qui ont des débits pas si catastrophiques que çà.

Pour les longues lignes (ordre de grandeur : > 4000 m) et/ou fortement atténuée (ordre de grandeur :
> 55 dB), la Freebox v3 n’est pas un très bon modem.

Elle ne permettra pas un débit très élevé, voire pas du tout de synchronisation avec le DSLAM. Mieux vaut alors investir dans un autre modem, de type Sagem ou Bewan, qui, en règle générale, s’en sortent mieux dans de mauvaises conditions de lignes.

A l’heure où ces lignes sont écrites il serait question d’un upgrade du firmware de la Freebox v3 qui permettrait de résoudre ces problèmes. Wait and see.

Il est normal d’avoir une atténuation supérieure pour le flux upload et on ne peut pas y faire grand chose (un nettoyage de ligne mais bon …)

Les fréquences utilisées pour les flux upload et download ne sont pas les mêmes et la plage de fréquence non plus.

La plage est beaucoup plus restreinte en upload.

Tout ceci fait que la ligne, à ces fréquences, est beaucoup plus parasitée et atténuée qu’aux fréquences utilisées pour le download.

( Pour faire une analogie un peu approximative : dans une boîte de nuit bruyante, on a aucun mal à entendre les gros « poum poum poum » d’un caisson de basse, alors que l’on a beaucoup plus de mal à entendre les cris stridents de sa copine ! à distance égale. )

C’est ce qui limite d’ailleurs le flux upload, indépendamment de la volonté du FAI.

« Noise margin » :

Deuxième nombre d’importance !

Il y a deux nombres, un pour l’upload (« up ») un pour le download (« down »)
Généralement vous serez surtout concerné par le chiffre pour le download.

Ce n’est PAS l’équivalent du « rapport signal à bruit » (SNR, Signal Noise Ratio)
pour les liaisons ADSL.

Plus ce chiffre est faible, moins bonne sera votre connexion : votre ligne sera davantage sensibles à certains types de parasites (bruits impulsifs).

De même que lorsque vous essayez de parler avec quelqu’un au téléphone, plus il y a de parasites sur la ligne, plus la transmission d’infos va lentement, vous devez répéter vos mots, vos phrases, etc.

Quelle est la bonne valeur pour le Noise Margin ?

Difficile à dire, cette notion agit comme une marge de sécurité :

– plus le Noise Margin est élevé, meilleure sera la résistance de votre ligne aux parasites, mais plus également son débit sera limité (« on assure » en quelque sorte). Ligne stable mais poins performante.

– à l’inverse si le Noise margin est faible, votre ligne sera plus sensible aux parasites, mais le débit maximal atteignable va (peut) augmenter. Ligne plus performante mais moins stable.

Si vous avez un Noise margin relativement faible ( ~ 6 à 10 db) et que votre
Chan data n’est pas très élevé malgré tout, c’est que votre ligne n’est pas
très bonne. Essayez de faire un nettoyage de ligne :

http://forum.touspourun.org/index.php?showtopic=6272

Généralement on observe une valeur de Noise margin entre 6 et 16 dB
(avec une Freebox, un autre modem pouvant amener d’autres valeurs)

Enfin le cas particulier du mode Patate : pour les très bonnes lignes (celles qui atteignent déjà le plafond du mode normal 7168/640) on va essayer d’aller encore plus loin, en allant jusqu’à la valeur du Attainable bitrate, si la valeur minimale de Noise margin n’est pas atteinte avant, sinon, on s’arrêtera avant que le Noise margin ne soit trop bas.

Il y a ensuite deux séries de rubriques identiques, selon que vous êtes en FastPath ou en Interleave.

« Fec » :

Forward Error Correction (ATM)

Technique de correction d’erreurs où il n’y a pas retransmission de données et donc où le destinataire est responsable de la correction des erreurs présentes dans le paquet. La FEC s’appuie sur la séquence de nombres contenue dans le champ données du protocole ATM AAL (ATM adaptation layer) 1 pour détecter la perte de cellules et éviter la transmission inutile de cellules appartenant aux paquets erronés.

« Hec »:

Header Error Control (Contrôle d’erreur sur l’entête) (ATM)

5ème octet de l’en-tête ATM qui contient les informations nécessaires à la sous-couche transmission convergence (TC) de la couche physique ATM pour détecter les erreurs de l’entête de la cellule ATM.
Si une erreur est détectée, la cellule est abandonnée avant sa transmission à la couche ATM

« Crc »:

Cyclic Redundancy Check (Code de redondance cyclique)

Mécanisme basé sur un algorithme mathématique permettant de détecter les erreurs sur les données (trame ou cellule). Le récepteur d’un bloc d’information détecte les erreurs de transmission en calculant le reste de la division de ce bloc par une constante et le compare à ce même reste mis dans le champ CRC du bloc d’information.

Au dela de ces définitions un peu techniques
(source : http://www.themanualpage.org/glossaire/glo_f.php3 ),
il s’agit en fait de compteurs de trois type d’erreurs différentes.

Un grand nombre d’erreurs seul ne veut rien dire.

Il faut rapprocher ce chiffre du nombre de cellules ATM transmises, c’est-à-dire diviser le nombre d’erreurs par le nombre de cellules.

Par exemple si vous avez :

Crc 30 (far) 5282 (near)

et

Rx cells 5346211
Tx cells 92601527

on divise :

30 / 92601527 = 0.000323968
5282 / 5346211 = 0.000987989

Les différences entre les deux taux (upload & download) s’expliquent en général par des chiffres d’atténuation différents pour l’un et pour l’autre. De même pour le « Noise margin ».

On considère qu’une bonne ligne ADSL à moins de 1 pour mille ( < 0.001) en taux d'erreur.

Dans de telles conditions, on peut passer en mode FastPath, sinon il vaut mieux rester en mode Interleave.

Le mode Fastpath est surtout intéressant pour les joueurs en ligne qui ont besoin d’avoir un « bon ping ».
Autrement dit, on grapille un peu en vitesse mais cela se fait en désactivant les contrôles d’erreurs.

La chaine de l’usine va plus vite parce que l’on ne vérifie plus ( ou moins) la qualité des boîtes de conserves qui sortent !

Donc on ne peut le faire impunément que sur de très bonnes lignes, ayant peu d’erreurs.
Activer le Fastpath sur une ligne ayant beaucoup d’erreurs ne fera qu’empirer la situation.

« Rx cells » :

Nombre de cellules ATM reçues *côté DSLAM*
(çà correspond en fait à votre upload, le flux de votre PC vers Internet)

Ce compteur est remis à zéro lors d’une déconnexion/reconnexion de la Freebox

Une cellule ATM a une longueur totale de 53 octets :

– 5 octets d’entête
– 48 octets « utiles »

Exemple :

Si vous avez 1 000 000 de cellules => 53 000 000 octets (ATM)
Ce qui fait en TCP/IP : 53 000 000 / 1.2 = ~ 44 166 667 octets

Formule de passage du nb de cellules à un chiffre en Mo TCP/IP :

soit « n » le nombre de cellules :

( ( n * 53) / 1.2 ) / 1048576 = z Mo (TCP/IP)

Par exemple, si vous avez un « Rx cells : 32568975 »

( ( 32568975 * 53) / 1.2 ) / 1048576 = ~ 1372 Mo (= ~ 1,37 Go)

Vous avez uploadé vers Internet environ 1,37 Go

« Tx cells » :

Nombre de cellules ATM émises *côté DSLAM*
(çà correspond en fait à votre download, le flux d’Internet vers votre PC)

Ce compteur est remis à zéro lors d’une déconnexion/reconnexion de la Freebox

Même calculs que ci dessus.

—

Historique :

v 1.21 : 26/09/2004 Mise à jour des informations concernant le Attainable bitrate et le Noise margin (merci à Hardline pour ses infos)
v 1.20 : 07/09/2004 Evolution pour tenir compte du mode PATATE : 7616/800
v 1.10 : 30/08/2004 Evolution pour tenir compte du débridage des débits maxi : 7168/640 au lieu de 5632/384
v 1.0 : 05/07/2004 version originale