Freebox optique débit/latence : Explications
Catégorie Brèves
, publié le 25 janvier 2008 à 16h33 par Frédéric Roy
Suite à l’article, publié par freenews, présentant la Freebox optique, nous avions pointé du doigt des débits peu probants pour une technologie FTTH.
Frédéric Gander, ingénieur chez Free, apporte quelques précisions :
surf a écrit :
> Je viens de voir l’article et je trouve pas terrible les débit et meme
> le ping .
>
> C’est en phase de test parce que quand on compare le ftth d’orange il il
> on bien le 100 Mbit/s => 12.5 Mo/s
Lo,
Petit début d’explication quand au résultat de ces test et de la latence :
sur la latence : entre pinger un site de paris à paris et pinger un site
de montpellier à paris c’est pas trop la meme chose.
1000 km de fibre pour remonter à paris à la vitesse de la lumiere ca
met 3.3ms
pour faire des transmissions longues distances le système est obligé
d’entrelacer les données pour corriger les pertes => presque 6 à 7 ms en
cumulant les 3 troncons fibres pour remonter à paris
et le reste (1 ms) est perdu dans les equipements de commutation IP
sur le chemin
en adsl vous avez la même chose mais en plus il faut rajouter la latence
du dsl soit 7 à 8 ms en fastpath et 20 30 en adsl classique .
au mieux sur l’adsl une personne de montpellier peut avoir 20 ms vers un
serveur de paris.
sur le debit :
le problème de débit vient de la latence et de la taille de fenêtre tcp
par défaut des ordinateurs
Pour resumer et faire simple le tcp permet d’envoyer une rafale de
données d’une certaine taille (taille de fenêtre) sans aquitement du pc
client.
Une fois cette taille atteinte, il "attend" un ACK du pc client (qui va
mettre 14 ms pour lui arriver)
conséquence : sur une connexion tcp avec une latence de 14 ms le débit
max qu’on peut atteindre sur un pc configuré par défaut est de
4 a 5 mo/s MAX.
pour pouvoir augmenter le débit de téléchargement il existe plusieures
solutions :
reduire la latence (pas trop possible de reduire les distances entre
paris et montpellier)
augmenter la taille de fenetre le serveur transfert plus de données
avant d’attendre l’ack du client => l’impact de la latence est donc
minoré car il y a moins de ack pendant le transfert.
lancer plusieurs connexions tcp
bien sur il faut aussi que le serveur en face arrive a suivre et qu’il
n’y est pas de shapping sur le serveur en face, que le pc client et le
serveur ne soit pas chargé niveau cpu/disque/etc par autre chose.
Si votre pc est chargé et qu’il met du temps à traiter vos données la
"latence" de la connection augmente et le débit chute.
PS : a 5mo/s ca fait quand même dans les 3000 paquets/seconde.
A+
Source : Newsgroup proxad.free.ffth
Frédéric Gander, ingénieur chez Free, apporte quelques précisions :
surf a écrit :
> Je viens de voir l’article et je trouve pas terrible les débit et meme
> le ping .
>
> C’est en phase de test parce que quand on compare le ftth d’orange il il
> on bien le 100 Mbit/s => 12.5 Mo/s
Lo,
Petit début d’explication quand au résultat de ces test et de la latence :
sur la latence : entre pinger un site de paris à paris et pinger un site
de montpellier à paris c’est pas trop la meme chose.
1000 km de fibre pour remonter à paris à la vitesse de la lumiere camet 3.3ms
pour faire des transmissions longues distances le système est obligéd’entrelacer les données pour corriger les pertes => presque 6 à 7 ms en
cumulant les 3 troncons fibres pour remonter à paris
et le reste (1 ms) est perdu dans les equipements de commutation IPsur le chemin
en adsl vous avez la même chose mais en plus il faut rajouter la latence
du dsl soit 7 à 8 ms en fastpath et 20 30 en adsl classique .
au mieux sur l’adsl une personne de montpellier peut avoir 20 ms vers un
serveur de paris.
sur le debit :
le problème de débit vient de la latence et de la taille de fenêtre tcp
par défaut des ordinateurs
Pour resumer et faire simple le tcp permet d’envoyer une rafale de
données d’une certaine taille (taille de fenêtre) sans aquitement du pc
client.
Une fois cette taille atteinte, il "attend" un ACK du pc client (qui va
mettre 14 ms pour lui arriver)
conséquence : sur une connexion tcp avec une latence de 14 ms le débit
max qu’on peut atteindre sur un pc configuré par défaut est de
4 a 5 mo/s MAX.
pour pouvoir augmenter le débit de téléchargement il existe plusieures
solutions :
reduire la latence (pas trop possible de reduire les distances entreparis et montpellier)
augmenter la taille de fenetre le serveur transfert plus de donnéesavant d’attendre l’ack du client => l’impact de la latence est donc
minoré car il y a moins de ack pendant le transfert.
lancer plusieurs connexions tcpbien sur il faut aussi que le serveur en face arrive a suivre et qu’il
n’y est pas de shapping sur le serveur en face, que le pc client et le
serveur ne soit pas chargé niveau cpu/disque/etc par autre chose.
Si votre pc est chargé et qu’il met du temps à traiter vos données la
"latence" de la connection augmente et le débit chute.
PS : a 5mo/s ca fait quand même dans les 3000 paquets/seconde.
A+
Source : Newsgroup proxad.free.ffth
COMMENTAIRES DES LECTEURS (21)
C'est clair que Freenews a vraiment joué au c** (et gagné :-/ ) en annonçant fièrement "Premier test d'une Freebox Optique", et en guise de test faire un vague download foireux absolument pas représentatifs.
Et les sites spécialisés de reprendre l'info de Freenews et de propager la fausse info que la freeebox optique a de mauvaises performances !
A croire que le test de Freenews a été mené par l'Ariase (des anti-free notoires) ou par le service marketing d'Orange ou de Neuf !!
Bravo Freenews, pour la gloriole de sortir les 1ers quelques photos en exclu, vous avez contribué à nuire à Free et à la freebox optique en pratiquant un test ridicule aux résultats foireux... :-(
Avec de tels débits que ceux du FTTH, ce n'est pas étonnant que le goulot d'étranglement se trouve du côté de l'abonné.
Dans le monde PC, des débits élevés n'étaient envisagés que dans une configuration LAN locale où les distances sont faibles donc les temps de latence négligeables, d'où cette configuration par défaut de la MTU.
Attendons donc de nouveaux tests avec une config utilisateur adaptée et un protocole de test plus poussé...
<quote>[http://fr.wikipedia.org/wiki/Maximum_Transmission_Unit->http://fr.wikipedia.org/wiki/Maximum_Transmission_Unit]</quote>
wikipedia.fr est une épouvantable "référence" en matière d'informatique.
<quote>IPv6 : le MTU par défaut vaut 4352 octets</quote>
Qu'est-ce que ça veut dire ?
Sur [http://fr.wikipedia.org/wiki/Maximum_Transmission_Unit->http://fr.wikipedia.org/wiki/Maximum_Transmission_Unit], cette absurdité :
<quote>IPv6 : le MTU par défaut vaut 4352 octets</quote>
est présente depuis le [29 mai 2007->http://fr.wikipedia.org/w/index.php?title=Maximum_Transmission_Unit&diff=prev&oldid=17415731#Exemple_de_valeur_du_MTU_selon_le_type_de_r.C3.A9seau].
Apparemment, c'est écrit d'après une "source" (mais il faut la chercher, ce n'est pas présenté correctement) : dans le [livre {IPv6 Théorie et Pratique} en ligne->http://livre.point6.net/index.php/Accueil], à l'article [Réseaux à diffusion->http://livre.point6.net/index.php/R%C3%A9seaux_%C3%A0_diffusion] se trouve effectivement cette phrase :
<quote>Le MTU IPv6 par défaut est de 4352 octets.</quote>
Évidemment, il faut aussi regarder le contexte, par exemple lire la phrase d'avant :
<quote>{{Pour FDDI}}, les datagrammes sont transmis dans des trames FDDI asynchrones avec jeton simple, chaque trame contenant un datagramme.</quote>
ou le titre de la section : "Encapsulation LLC".
Le simple fait d'essayer de comprendre le contexte de la phrase aurai suffit à éviter une telle erreur. La moindre notion du rôle d'IPv6 aussi.
Le fait d'avoir une (toute) petite idée de quoi on parle n'est pas un pré-requis sur Wikipédia. Il suffit d'avoir une {source} (en théorie - en pratique, ce n'est pas obligatoire non plus). Alors n'importe quelle énormité peut être écrite - et rester : l'article a été modifié 13 fois depuis pratiquement 6 mois (et lue combien de fois ?).
Si une source contient une faute de frappe, ça doit-elle se retrouver copiée sur Wikipédia ?
Wikipédia : ce n'est pas parce que ça tombe en premier sur Google que c'est ça qu'il faut utiliser. (WP:CNEPPQCTEPSGQCCQFU)
Réflexion sur les méthodologies de Test. Sur les tests de haut débit, pas de salut sans agrégation de flux. 100Mbps c'est trop de charge pour un seuls serveur pour supporter ne serait-ce que quelques connexions simultanées. Nouvelle contraintes, nouvelles méthodologies!
Le MTU est une contrainte clef pour le test de débit avec une seule source, mais l'est beaucoup moins quand il y a plusieurs sources. Idem pour la proximité entre le serveur de test et le client.
Pour la latence les mesures sont plus simples et ne changent pas avec le débit.
Bref pour mesurer la performance des accès Internet par fibre optique il faudra attendre de nouveau services, ou charger de gros fichier avec agrégation de débit offert part les gestionnaires de téléchargements.
En attendant faites nous vos retours sur vos expérience de test haut débit [test.haydont.net->http://test.haydont.net] et en particulier sur le nouveau script SpeedTest v7.0b4 que mesure maintenant les débits montants, descendants et le temps de latence!
Bon Surf!
INSERER UN COMMENTAIRE







![[Film] JE PRÉFÈRE QU’ON RESTE AMIS...](IMG/arton10509.jpg)
![[Film] VIOLENCE DES ÉCHANGES EN MILIEU TEMPÉRÉ](IMG/arton10494.jpg)
![[Téléfilm] AU BONHEUR DES HOMMES](IMG/arton10485.jpg)
![[Documentaire] A CONTRE-COURANT](IMG/arton10476.jpg)
![[Musique] AMY WINEHOUSE](IMG/arton10470.jpg)


Modification de la numérotation sur (...)





