Les transferts se font via internet, ou les deux machines sont sur le même réseau local?
En remarque, je dirai qu' SMB n'est pas fait pour transférer des fichiers en interconnexion de réseaux, contrairement à FTP.
Le fait que les petits fichiers aient des vitesses de transferts nettement inférieures aux gros est normal.
C'est lié aux phases de débuts et de fin de transfert qui sont lentes, et prennent le même temps, que le fichier soit volumineux ou pas.
Pour un fichier volumineux, ces phases de démarrage ne plombent pas les vitesses globales de transfert. Pour les petits fichiers, oui.
De plus, si le protocole de transfert (smb, ftp) de fichiers s'appuie sur TCP, il faut prendre en compte le fait qu'il utilise un dispositif dit de "démarrage lent". Comme TCP ne connait pas la bande passante disponible entre deux machines, il démarre lentement (utilisation des fenêtres d'anticipation du protocole TCP), et monte progressivement en débit. Donc, là aussi, les petits fichiers sont pénalisés par cette phase qui plombe les perfs.
Après, il y a le contexte des transferts à prendre en compte.
Là aussi, c'est lié à TCP.
Par exemple, dans le sens client vers une machine virtuelle, la pile TCP de la machine virtuelle communique (dans chaque paquet) au client la taille (en octets) disponible dans son buffer en réception (TCP windows size). La couche TCP régule ainsi la vitesse de transfert. Elle peut même arrêter (momentanément) le transfert le temps qu'elle vide son buffer en réception.
On peut constater ce genre de pb en faisant une analyse protocolaire avec wireshark, par exemple.
Il faudrait aussi regarder le taux de réémission (côté émetteur) en faisant un "netstat -s"
Si ça ce trouve, ce n'est qu'un pb de qualité de ligne.
Si il y a de la perte, il y a retransmission des paquets, et c'est l'effet "boule de neige" sur le réseau. La cata...
Mais bon, tout ça, c'est de la théorie, et ça ne résoud pas ton pb...
