Retourner aux forums || Retourner au forum Linux.redhat
Linux.redhat : Vitesse transfert et scp
Posté par TNorth () le 22 janvier 2007Sur une RedHat 9, noyau 2.4 et carte réseau reconnue (dmesg) comme Full Duplex, j'ai des différences de transferts machine à machine énormes :
Scp, avec compression : 2.5MB/s
sans compression : 2.6 MB/s
Samba (vers une machine windows) : 6.5MB/s
Y a-t-il une option à passer à SSH pour accélérer le transfert ?
Avez-vous expérimenté un cas similaire ?
J'ai des grosses masses de données à déplacer, et utiliser scp serait un plus (pas tout est dans les samba shares) ...
Merci !
> Lire le message (9 commentaires, moyenne: 1,6).
.
et la charge CPU elle est comment ? Parce que tout passer dans un tunnel chiffré ca a un cout.
-
[^]Re: .
Et avec du FTP ?
(donc, sans overhead de chiffrement - plus près de ce que fait samba)
-
[^]Re: Et avec du FTP ?
Posté par TNorth () le 22/01/2007 à 10:59. (lien). Évalué à 1.Je n'ai malheureusement pas la possibilité de tester ce mode de transfer facilement. (pas ma machine)
Je vais tenter rsync par contre ... cela pourrait être intéressant.-
[^]Re: Et avec du FTP ?
Posté par Nicolas Boulay () le 23/01/2007 à 09:33. (lien). Évalué à 2.tu peux essayer scp -c blowfish qui est un cipher moins demandant que l'aes (cypher par défaut il me semble).
--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
Peut-être un coup d'oeil par là ?
-
[^]Re: Peut-être un coup d'oeil par là ?
Posté par TNorth () le 22/01/2007 à 12:05. (lien). Évalué à 1.Merci du lien, je suis effectivement tombé sur cette page il y a quelque temps, mais j'avais de la peine à croire que la limitation soit due à SSH et pas à ma config.... peu de personnes semblent avoir ce problème, et on parle toujours de ssh/scp comme "a fast and secure blabla" non ?
Je vais voir si je parviens à recompiler tout ça...-
[^]Re: Peut-être un coup d'oeil par là ?
Posté par TNorth () le 22/01/2007 à 12:16. (lien). Évalué à 1.Ah et une info de la FAQ de HPN-SSH :
Q: I installed HPN-SSH but there is no improvement. Why not?
A: There are many possible answers to this but its important to understand that HPN-SSH will not make every transfer faster. Transfers in a local area network will not be improved by HPN-SSH and in some case might even be slower (in these cases use the -o HPNDisabled=yes option). You also have to make sure that your computer's network stacks are properly tuned. This is especially critical on the reciever side of the connection. Please see PSC's TCP Tuning page for details on how to do this. You might also be limited by firewalls, packet loss, network errors, and other problems that can affect network performance.
-
[^]Re: Peut-être un coup d'oeil par là ?
Posté par alenvers () le 22/01/2007 à 14:04. (lien). Évalué à 2.Hum, scp a tendance à vouloir gérer les buffer lui-même. Je pense que le problème est du même accabit que le problème de window size trop petit pour TCP.
>Transfers in a local area network will not be improved by HPN-SSH and
> in some case might even be slower
Je pense que cela veut dire que si le délai (rtt - ping) sur le chemin entre les 2 serveur est très petit, il n'y a pas de problème.
Pour TCP, on calcul aisement la taille minimale de buffer pour avoir de bonnes performances :
Bandwidth * delay = taille du buffer minimal.
Si le délai est très très petit (Sur un lan par exemple), généralement les perfs sont bonnes avec les configs par défaut. Dans le cas d'un délai plus grand (firewall entre les 2 machines, routers, ...), les problèmes arrivent.
Le patch a l'air de tuner la taille de ces buffers donc, cela me semble un bon plan (même parfois sur le même lan, cela dépend du délai).
-
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.redhat
Cette page a été générée par Templeet en 0.077s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.