Nous avons une paire de nouvelles liaisons Ethernet 1 Gbit / s à routage divers entre des emplacements distants d'environ 200 miles. Le `` client '' est une nouvelle machine raisonnablement puissante (HP DL380 G6, double E56xx Xeons, 48 Go DDR3, paire R1 de 300 Go de disques SAS à 10 000 tr / min, W2K8R2-x64) et le `` serveur '' est également une machine suffisamment décente (HP BL460c G6 , double E55xx Xeons, 72 Go, paire R1 de 146 Go de disques SAS à 10 000 tr / min, HBA Emulex 4Gbps FC à double port lié à deux Cisco MDS9509, puis sur HP EVA 8400 dédié avec 128 disques FC de 450 Go à 15 000 tr / min, RHEL 5.3-x64).
En utilisant SFTP du client, nous ne voyons qu'environ 40 Kbps de débit en utilisant des fichiers volumineux (> 2 Go). Nous avons effectué des tests de serveur à `` autre serveur local '' et voyons environ 500 Mbps via les commutateurs locaux (Cat 6509s), nous allons faire de même côté client, mais c'est dans un jour ou deux.
Quelles autres méthodes de test utiliseriez-vous pour prouver aux fournisseurs de liens que le problème est le leur?
la source
Réponses:
Accorder un éléphant:
cela pourrait nécessiter un réglage, probablement pas le problème ici, comme le dit pQd. Ce type de lien est connu sous le nom de "Long, Fat Pipe" ou éléphant (voir RFC 1072 ). Comme il s'agit d'un gros tube gigabit parcourant une distance (la distance est vraiment le temps / la latence dans ce cas), la fenêtre de réception TCP doit être grande (voir le volume illustré TCP / IP 1, section Extensions TCP pour les images).
Pour déterminer ce que doit être la fenêtre de réception, vous calculez le produit de retard de la bande passante:
S'il y a une latence de 10 ms, cette calculatrice estime que vous voulez une fenêtre de réception d'environ 1,2 Mo. Nous pouvons faire le calcul nous-mêmes avec la formule ci-dessus:
Donc, vous voudrez peut-être exécuter un vidage de paquet pour voir si la mise à l'échelle de la fenêtre TCP (l'extension TCP qui permet des fenêtres plus grandes) se produit correctement pour régler cela une fois que vous avez déterminé quel est le problème majeur.
Window Bound:
Si c'est le problème, que vous êtes lié à la taille de la fenêtre sans mise à l'échelle, je m'attendrais aux résultats suivants si aucune mise à l'échelle de la fenêtre n'est en place et qu'il y a environ 200 ms de latence quelle que soit la taille du tuyau:
Donc:
Pour obtenir les résultats que vous voyez, il vous suffit de résoudre la latence, qui serait:
Donc (pour 40 Ko / s):
(Veuillez vérifier mes mathématiques, et celles-ci n'incluent bien sûr pas tous les frais généraux de protocole / en-tête)
la source
40kbps est très faible [au point que je soupçonne des convertisseurs de média défectueux / une discordance de duplex [mais vous avez du gigabit donc il n'y a pas de place pour le half duplex!] Etc.]. il doit y avoir des pertes de paquets ou une gigue très élevée.
iperf est le premier outil qui me vient à l'esprit pour mesurer le débit disponible. courir d'un côté
et d'autre part:
Ensuite, vous pouvez échanger les rôles client / serveur, utiliser -d pour duplex, etc. exécuter mtr entre les deux machines avant le début du test et voir quelles pertes de latence / paquets vous avez sur la liaison inutilisée, et comment changent-elles pendant le transfert de données.
vous aimeriez voir: une très petite gigue et aucune perte de paquets jusqu'à ce que le lien soit saturé à 90% de sa capacité.
iperf pour * nix et gagnez , lisez ici et ici à ce sujet.
mtr pour * nix et gagner .
la source
tracepath peut vous montrer des problèmes de routage entre les deux sites.
iperf, ttcp et bwping peuvent vous fournir des informations utiles.
savez-vous comment ce lien de 1 Go est provisionné? pontez-vous ou routez-vous sur ce lien? Quel est votre SLA pour le lien? vous pourriez être façonné par votre fournisseur de liens?
si vous n'obtenez que 40 Ko, alors il y a un problème grave, êtes-vous sûr que ce n'est pas un lien de 1 Mo plutôt qu'un lien de 1 Go / s. Vous constaterez probablement que la vitesse du lien n'est pas ce que vous en pensez :-)
la source
RFC 2544 ou Y.156sam
Ce sont des tests de réseau qui sont effectués pour prouver le SLA par le transporteur. IPERF et similaires ne sont pas des méthodes de test réseau vérifiables.
la source