Temps de latence SDSL

Support Debian
#1

salut les milouzes :smt006

pour ceux qui penseraient que ce problème n’a rien a voir avec debian, peut être que oui, mais comme j’ai confiance dans notre distrib préféreé j’immagine bien qu’elle va me proposer une solution. :mrgreen:

bon voila le problème :

j’ai deux sites inter-connectés par une liaison transfix (point à point) mes temps de réponses sont les suivants :

user@debian:~$ ping machine.sitedistant.com
PING machine.sitedistant.com (x.x.x.x) 56(84) bytes of data.
64 bytes from machine.sitedistant.com (x.x.x.x): icmp_seq=1 ttl=126 time=3.22 ms
64 bytes from machine.sitedistant.com (x.x.x.x): icmp_seq=2 ttl=126 time=3.19 ms
64 bytes from machine.sitedistant.com (x.x.x.x): icmp_seq=3 ttl=126 time=3.20 ms
^C
--- machine.sitedistant.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2015ms
rtt min/avg/max/mdev = 3.190/3.207/3.229/0.016 ms
user@debian:~$

je viens de résilier cette ligne pour une liaison SDSL (VPN/MPLS opérateur), même débit, mais les temps de latence ont sévèrement augmenté ils sont desormais à plus de 60 ms pour le même test. et forcement l’impact sur les applications est assez conséquent ce qui me vaut pas mal de reproches des utilisateurs.

comme je suis breton et tétu je n’envisage pas pour l’instant de revenir en arrière et je me demande plutôt si il n’existerai pas des solutions permettant d’améliorer cette situation. je sais bien que je ne peux pas intervenir sur le reseau de l’operateur, mais est ce que en posant un boîtier debian de chaque coté de la liaison il existe des softs qui permettraient d’optimiser le trafic ?

pour info, en terme de débit je suis ok. j’ai fait des tests en FTP et je downoad bien au débit annoncé par l’operateur, et la ligne n’est pas surchargée. c’est vraiment juste une histoire de temps de réponse.

j’attend vos solutions avec impatiences, je me suis retranché dans mon bureau car mes utilisateurs veulent me lyncher. :smt005

sauvez moi :smt006

thomas

#2

Si je comprends bien, la nouvelle liaison est constituée comme suit :

La technologie xDSL est caractérisée par une latence non négligeable, notamment à cause de l’entrelacement (interleave) qui a pour but de lutter plus efficacement contre les erreurs de transmission dues aux perturbations impulsionnelles. Je n’ai pas d’expérience spécifique de ces technologies, mais ce temps de latence pour la traversée de deux lignes SDSL et un MPLS opérateur ne me choque pas outre mesure.

Hélas, malgré toutes ses qualités, Debian ne peut passer outre les lois de la physique.
Par curiosité, quelles sont les applications affectées par ce temps de latence ?

#3

les appli affectées : toutes en fait.

bon il faut dire que niveau bureautique ils utilisent des fichiers vraiment énormes, ils ne comprennent pas que c’ets pas une bonne façon de travailler.

sur notre ERP en mode web c’est génant (lui aussi est très gourmand, bourré de java, d’activex et autres merdes, en fait pour moi c’est du web mais ça reste un client lourd, ces gens là n’ont rien compris, ils ont juste redeveloppé leur client lour en javascript :imp: )

le pire étant les clients louds utilisant ODBC pour se connecter à un serveur oracle. là c’est la catastrophe.

ce que je me demandais c’est si on ne pouvait pas utiliser un sorte de compression ou autre à l’interieur d’un tunnel afin d’alleger le trafic. mais bon je crois que ce sont des solutions utilisées plus en cas de saturation de debit que de temps de latence.

au cas ou j’ai demandé à mon operateur de voir si leurs gestion de QoS ne pouvait pas être un peu revue à la baisse, j’ai vu sur certains site que la QoS bouffait aussi de la latence.

mais bon, merci pascal pour ce message d’espoir. :frowning:

#4

Comme tu l’observes, le débit de transfert d’un gros fichier par un protocole efficace basé sur TCP (par exemple FTP ou HTTP mais pas TFTP, et je reste réservé concernant NFS ou SMB/CIFS) ne souffre pas de l’augmentation de latence jusqu’à une certaine limite qui est le quotient RWIN/RTT.
RTT = Round Trip Time, le temps d’aller-retour entre l’envoi d’un segment et la réception de son acquittement, l’équivalent de la latence du ping en quelque sorte
RWIN = Receive WINdow, taille de la fenêtre de réception TCP, limitée à 64 Kio si l’option TCP Windows Scaling (facteur d’échelle de fenêtre TCP) n’est pas utilisée, beaucou plus dans le cas contraire.
En supposant que cette option n’est pas utilisée, le débit effectif d’une connexion TCP avec un RTT de 60 ms serait donc limité à 64 Kio / 60 ms = 1 Mo/s à la louche, soit 8 Mbit/s.

Mais… la latence augmente avec la taille des paquets, car chaque mise en tampon du paquet par un équipement réseau introduit un délai proportionnel à sa taille et à la vitesse de l’interface ; plus la vitesse de la liaison est faible, plus le délai augmente. Il suffit de faire varier la taille des paquets dans ping sur différents types de liaisons pour s’en rendre compte. La latence augmente aussi avec l’occupation du lien : si on n’est pas tout seul à envoyer des paquets, il faut attendre son tour. Les deux vont souvent de pair car ce sont les gros transferts qui utilisent de gros paquets. En tout cas la latence à prendre en compte est celle mesurée en charge, pas à vide.

Je ne sais pas si la QoS fait augmenter la latence, mais une bonne QoS peut diminuer le RTT effectif en favorisant les petits acquittements par rapport aux gros segments de données. De même, elle peut favoriser certains types de trafic qui ont besoin de réactivité. Si l’opérateur ne peut le faire, tu peux le faire avec des routeurs dédiés de part et d’autre de la liaison ou éventuellement avec des machines sous GNU/Linux. La compression dans un VPN, en réduisant la taille des paquets de données, pourrait aussi diminuer la latence liée à la taille des paquets dont j’ai parlé plus haut, mais le gain éventuel est à comparer au temps de traitement supplémentaire.

Tu peux éventuellement demander à l’opérateur de diminuer l’entrelacement des liaisons SDSL pour diminuer la latence, mais cela risque d’être au détriment de la fiabilité.

#5

merci pascal c’est très complet. comme d’habitude.
mais il faudra que je relise deux ou trois fois avant de rentrer dedans… là j’ai encore rien compris.

tiens, j’ai trouvé une photo de toi sur internet… enfin là en ce moment c’est comme ça que je t’immagine. en train de venir tester les rtt et autres truc sur ma ligne sdsl.