Taux de transferts et commandes scp

Support Debian
#1

Hello,

J’ai un client qui se plaint de n’avoir eu que 3.5 mbs durant son téléchargement de 105Go de fichiers par scp, entre ses deux machines du lan.

Effectivement ça me parait correspondre à ce que je vois via mes monitorings.
Néanmoins, je n’ai pas l’impression que ce soit anormal.

A priori, le taux de transfert dépend de quoi?
Des disques ? (vitesses de lectures écritures - ici, le contrôleur est du SAS 146 GB HDD IBM.
De la configuration des cartes réseaux ? (ici, c’est du 100).

Typiquement :

=> Interface eth0 :
Adressage IP :
Auto-negotiation: off
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
Link detected: yes
=> Interface eth1 :
Adressage IP :
Auto-negotiation: off
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
Link detected: yes

Selon lui, les données indiquaient : 3.5 Mb/secondes.

Cela doit dépendre aussi de la commande utilisée, je supppose.
scp, par exemple, n’est pas ftp. Du reste scp étant sécurisé, il faut le crypter et le “décrypter” ce qui doit aussi prendre du temps.

En fait, j’aimerais y voir plus clair. Comment je peux expliquer plus précisémment ce taux, comparé au 100 prévu en speed?

Ce que je peux dire :
pas de problème sur le réseau. Pas de problème de transmission des données (pas d’alertes netstat, pas de paquets jetés)

Il y aurait, quelque part, quelqu’une qui aurait une idée, ou une liste de différentes commandes/protocole utilisables pour le téléchargement, avec leur taux de transfert ?
Tout ça me permettrait déjà d’y voir plus clair, car je ne comprends pas bien.

PS. La machine distante n’est plus là. J’aurais fait d’autres tests, sinon.

Merci d’avance!

Rgs,
Christian

#2

premierement 100 est une vitese theorique

deuxiemement cette vitesse est exprimée en mega bits par seconde, et la plupart des soft expriment des vitesses en byte par seconde ou en octets par seconde, il faut donc appliquer une multiplication par 8 pour avoir une vitesse en mega bits par seconde pour comparer avec le débit réseau. donc essaye de donner des unitées complètes.

ensuite c’est vrai que avec plein de fichiers, tu n’arriveras pas a un debit maximal.

c’est vrai que le meilleur moyen (pour moi) de tester serait deja de faire du FTP , le même fichier, 10 ou 20 Mega et depuis plusieurs postes du réseau. tu verras en gros les vitesses maxi que tu peux atteindre. un conseil, avant de lancer les tests fait un reset des logs et des stats sur tes switchs, comme ça en cas de probleme tu pourras voir si une interface a plus de problemes que les autres.

ensuite pour scp c’est clair que le cryptage va faire perdre du debit ‘utile’. mais pas trop quand même.

en esperant te mettre sur une piste…

@+

#3

Si c’est plus rapide en ftp qu’en scp (en oubliant un pb de firewall) alors ca pourrait aussi etre la partie cryptage et donc une des 2 cpus qui rame.
Il faudrait faire un test ftp du débit.

#4

ok

Merci pour votre retour à tous les deux!

le cryptage + le débit théorique + le fait qu’il y a des requêtes réseaux qui vont et viennent sur la machine + la taille des fichiers + la vitesse d’écriture sur le disque (encore qu’avec du SAS - je ne connais pas très bien - ça doit bien tourner, en principe), toussa ensemble, ça doit jouer.

En fait, j’ai vu des tests - mais sur des forums :s - à propos de scp, qui permettrait des débit à 4 mbs, max. j’aurais bien voulu avoir des comparaisons, des stats à peur près fiables quelques part, mais je n’en trouve pas.
Je ne suis donc officiellement sûr de rien.

A moins de reproduire le débit via un nouveau transfert, ça va être difficile de vérifier.

J’essaierai de donner plus de détails, lundi sur ce que j’ai comme infos.

Ce qui me manque un peu, en fait, c’est une “échelle”. Pour du 100, une bon débit, en réel, ça représenterait quoi? :s Je ne crois pas qu’il y ait de réponse simple.

En tout cas, merci.

#5

Je fais du scp tous les jours mais j’ai jamais vraiment regardé mon debit effectif. Je regarderai Lundi sur du 100Mb/s switché.

#6

dis toit que la vitesse de transfert entre les deux pc sera la vitesse du composant le plus faible. à toi de trouver de quel composant il s’agit (hdd, carte reseau, switch, cable reseau, …)

par exemple tu peux tester tes disques avec la commande hdparm

sur le reseau 100 est la vitesse ‘bas niveau’, la vitesse physique. si tu tiens compte des collisions, des retransmissions, … (CSMA/CD) et du trafic des autres machines, tu verras qu’on en est encore loin des 100MB même pour les trames ethernet. ensuite si tu tiens compte des encapsulations, contrôle de flux, signalisation, … des sept couches successives, entre la vitesse physique du réseau et la vitesse ‘utile’ on en prends un coup.

et surtout la plus important à mon avis, soit très attentif aux unitées de mesure, essaye toujours de savoir exactement en quelle unité est donné tel ou tel résultat.

#7

Non.

Voilà, c’est mieux. Avec l’unité de mesure, ce serait parfait.

En environnement commuté (avec des swiches, pas des hubs) en full duplex, il n’y a plus de collisions ni de retransmissions de trames ethernet (ce qui n’exclut pas les retransmissions de segments TCP le cas échéant, mais c’est une autre histoire).

Avec un protocole efficace et léger comme FTP, on peut facilement atteindre voire dépasser 10 Mo/s de débit utile en fast ethernet. Le débit réel dépend néanmoins d’autres possibles goulets d’étranglement. Un exemple : mon routeur est un vieux PC sous Debian avec une interface ethernet 10Mbit/s largement suffisante pour le débit de la liaison ADSL. Il m’arrive de transférer des fichiers entre ce routeur et un poste du réseau local avec Filezilla. En FTP je dépasse 1 Mo/s comme prévu alors qu’en SFTP (transfert de fichier par SSH) je plafonne à 300 ko/s. Jamais vraiment compris pourquoi, alors que la charge CPU des deux machines pendant le transfert est loin en dessous de 100%.

#8

Hello,

Merci Pascal.

Votre retour m’a été utile. :slightly_smiling:

Bonne journée à toi.