Pourquoi la mise à niveau de ma bande passante n'a-t-elle pas accéléré la copie de mes fichiers ?

"Nous venons de passer d'un T1 (1,544 mbps) à un T3 (44,736 mbps), alors pourquoi faut-il encore 90 minutes pour copier ce fichier ?

La réponse est simple : plus de capacité n'est pas la même chose que des octets plus rapides. Si vous augmentez votre capacité de près de 29 fois (44.736 / 1.544), vous pourrez peut-être copier 29 fichiers dans les mêmes 90 minutes, mais vous ne pourrez probablement pas copier ce fichier plus rapidement. J'ai abordé ce sujet l'année dernière sur le blog intitulé "Problèmes de performance et de latence des applications", mais je pense que les transferts de fichiers et le copy_file nécessitent un blog plus ciblé.

La clé est liée à la taille des fenêtres, c'est-à-dire au nombre d'octets que l'hôte/l'application d'envoi peut envoyer sans devoir s'arrêter et attendre un accusé de réception de l'hôte/l'application de réception. Certaines applications comme le FTP n'ont pas d'accusé de réception de la couche application et s'appuient sur le TCP. Dans ce cas, la taille de la fenêtre est basée sur ce que la couche TCP de l'hôte distant annonce, jusqu'à 64K octets, ce qui est le maximum pris en charge par le STCP. Certaines applications ont une fenêtre de la couche application, pour ces applications la fenêtre limite est la plus petite des fenêtres TCP et application.

Le débit maximal est calculé comme suit

W / RTT = T

Où

W est la taille de la fenêtre en octets

RTT est le temps aller-retour en secondes

T est le débit en octets par seconde

Le temps aller-retour est le temps qu'il faut pour envoyer certaines données et obtenir l'accusé de réception. Pour les grandes distances, c'est-à-dire le cross-country, ce temps est principalement basé sur la distance que les octets doivent parcourir et la vitesse de traitement de tous les équipements du réseau entre les points terminaux. La vitesse de traitement de l'hôte récepteur, la taille des paquets (valeur TCP MSS, voir "Un moyen facile d'améliorer le débit sur les sous-réseaux") et bien sûr la largeur de bande du lien le plus lent jouent un rôle moins important.

Par exemple, si la RTT est de 0,050 seconde et la fenêtre de 64K, le débit maximal sera de 1 310 720 octets par seconde (64 * 1024 / 0,050). Tant que la capacité inutilisée de la liaison est supérieure au débit, l'augmentation de la capacité n'accélérera pas le temps de transfert.

T est le débit maximal possible. Rien de ce que vous faites (sauf augmenter la fenêtre ou réduire le RTT) ne peut accélérer les choses MAIS des conditions de réseau hostiles peuvent les ralentir considérablement.

Pour estimer le temps de transfert, il suffit de diviser la taille du fichier par le débit

F/ W * RTT = Ti

Où

F est la taille du fichier en octets

W est la taille de la fenêtre en octets

RTT est le temps aller-retour en secondes

Ti est le temps en secondes pour transférer le fichier

OSL a une taille de fenêtre d'application de 4K, le système de fichiers OpenVOS rapporte les tailles de fichiers en blocs de 4K octets ; pour estimer le temps de copie d'un fichier entre deux systèmes OpenVOS en utilisant la commande copy_file, il suffit de

F * RTT = Ti

Où

F est la taille du fichier en blocs

RTT est le temps aller-retour en secondes

Ti est le temps en secondes pour transférer le fichier

Sur une liaison avec un RTT de 0,050 seconde, il faudra un peu plus de 41 minutes à l'OSL pour copier un fichier de 50 000 blocs (50 000 * 0,05). Le débit maximal sera de 81 920 octets par seconde (4096 / 0,050). Tant que la capacité de réseau inutilisée de votre lien est supérieure à 81 920 octets par seconde, l'ajout de capacité ne réduira pas le temps nécessaire pour copier le fichier.

Le moyen le plus simple de mesurer le temps aller-retour est le ping. Malheureusement, ping ne donne pas un seul chiffre pour la RTT mais plusieurs chiffres et les chiffres peuvent varier considérablement, par exemple :

Si vous souhaitez calculer le meilleur débit possible, utilisez le chiffre le plus bas. Si vous souhaitez obtenir une estimation raisonnable de ce à quoi vous devez vous attendre, utilisez un nombre ping de 10, jetez les deux nombres les plus élevés et les deux plus bas et faites la moyenne du reste.

Comme je l'ai dit plus haut, un réseau hostile peut ralentir considérablement les choses. Les temps d'attente Ping en sont une indication. Ainsi, tout délai signifie que ces calculs sont probablement très optimistes. Les transferts peuvent également être ralentis par des disques et/ou des CPU occupés qui empêchent l'émetteur de lire et d'envoyer les données aussi vite que possible ou qui font que le récepteur lit les données plus lentement que leur vitesse d'arrivée, ce qui retarde les accusés de réception des applications (augmentant le temps d'aller-retour) et éventuellement remplit les tampons de réception TCP, ce qui fait que l'hôte émetteur cesse de transmettre. Le seul moyen de savoir si l'une de ces conditions s'applique est de suivre la trace des paquets.