Accellerer les transferts SMB

On Sat, 30 Dec 2006 15:33:18 +0100, "Eric Leconte"
<eric.leconte@laposte.net>:

Pourquoi ne pas utiliser VLC qui permet la vision de films via le reseau

Si le débit est insuffisant, je ne vois pas bien comment VLC peut
améliorer les choses. En recompressant à la volée avec une qualité
moindre ?

ou tout simplement effectuer une copie locale temporaire.

Même remarque : si le débit est insuffisant, pour un film d'une heure
et demi, la copie risque de demander deux heures, et l'OP n'est pas
près de commencer à regarder le film...

Le Sat, 30 Dec 2006 11:08:09 +0100, Zouplaz <user@domain.invalid> a écrit:

Bonjour, j'ai un portable VAIO sous Fedora 4 qui papotte avec un serveur
sous CentOS via une liaison WIFI. Lorsque je fais un transfert FTP entre
les deux j'arrive à un taux qui oscille entre 1,2 et 1,5 Mo/s

Quand je visualise un fichier divx directement à partir du serveur
(mount smb donc) le son est haché et parfois l'image se gèle quelques
millisecondes :

- est-ce que ça provient du débit qui n'est pas suffisant ?
- est-ce que c'est un problème de conf de samba côté serveur ?

Merci

Pourquoi ne pas utiliser VLC qui permet la vision de films via le reseau
ou tout simplement effectuer une copie locale temporaire.
Je sais ce n'est pas une solution, mais ca regle pas mal de problemes :)

Sinon je n'ai pas l'impression que l'isntall samba de base que j'ai faite
chez moi effectue ce genre de probleme. La connectivite est comme de
Windows a Windows.

Par contre j'ai arreter le wifi pour la simpel raison que la limite de la
bande passante WIFI actuelle (quand j'ai un taux optimal) est inferieure a
ma connectivité internet. Et la effectivement j'avais un taux de transfert
inferieur au mega par seconde.

Je pense que ton pb viens plus de la limite de la bande passante WIFI.

le 30/12/2006 15:06, Fabien LE LEZ nous a dit:

On Sat, 30 Dec 2006 15:33:18 +0100, "Eric Leconte"
<eric.leconte@laposte.net>:

ou tout simplement effectuer une copie locale temporaire.

Même remarque : si le débit est insuffisant, pour un film d'une heure
et demi, la copie risque de demander deux heures, et l'OP n'est pas
près de commencer à regarder le film...

Exact, pas une heure mais 10 bonnes minutes à chaque fois... Ca laisse
pas trop de temps pour l'improvisation ;-)

Je me demande si un peu de tuning samba pourrait pas faire l'affaire,
taille de paquets, envoi prédictif, que sais-je...

On Sat, 30 Dec 2006 11:08:09 +0100, Zouplaz <user@domain.invalid>:

- est-ce que ça provient du débit qui n'est pas suffisant ?

Commence par évaluer la vitesse de la couche TCP/IP.

Par exemple, tu peux transférer 50 Mo de données d'une machine à
l'autre, et voir combien de temps ça prend :

1- Sur une machine :

nc -l -p 53456 > /dev/null

(53456 est le numéro de port ; n'importe lequel devrait convenir.)

Apparemment, il faut omettre le "-p" avec certaines versions [?]


2- Sur l'autre machine :

dd if=/dev/zero bs=1M countP |time nc ip_machine_1 53456

Si le transfert de ces 50 Mo prend beaucoup de temps, il y a de
grandes chances pour que le problème vienne de la couche réseau.
Si ce transfert prend nettement moins de temps que le transfert d'un
Mo par SMB, c'est que Samba a un problème.

Fabien LE LEZ wrote in message
<vp2dp2dakrae70bvvp5dl87k54p8t1oqf5@4ax.com>:

dd if=/dev/zero bs=1M countP |time nc ip_machine_1 53456

Avec une ligne comme ça, il y a de bonnes chances que dd fasse des écritures
partielles, ce qui n'est pas bon. Accessoirement, les GNU dd récents
affichent des statistiques de vitesse à la fin, donc ce n'est pas la peine
de mettre un time.

On 30 Dec 2006 16:37:04 GMT, Nicolas George
<nicolas$george@salle-s.org>:

dd if=/dev/zero bs=1M countP |time nc ip_machine_1 53456

Avec une ligne comme ça, il y a de bonnes chances que dd fasse des écritures
partielles, ce qui n'est pas bon.

De quoi s'agit-il ?

Accessoirement, les GNU dd récents
affichent des statistiques de vitesse à la fin

Mais puis-je être sûr que les statistiques affichées par dd concernent
la vitesse de transmission de nc ?

Fabien LE LEZ wrote in message
<5f6dp2p08mssr3l61guhkc17riaks2gc1p@4ax.com>:

De quoi s'agit-il ?

Quand un programme demande à l'OS d'écrire des données vers un fichier ou un
pipe, il fournit une certaine quantité de données, mais l'OS peut en écrire
moins. Par exemple dans un pipe, la quantité écrite sera la place restante
dans le buffer du pipe. C'est au programme de comparer la quantité
effectivement écrite (retournée par l'OS) avec la quantité qu'il voulait
écrire, avec quelque chose comme :

while(to_write > 0) {
if((written = write(fd, data, to_write)) < 0)
error("XXX");
to_write -= written;
data += written;
}

dd ne fait aucun effort pour ré-écrire la fin de ses blocs, ça fait partie
de sa spécification.

Mais puis-je être sûr que les statistiques affichées par dd concernent
la vitesse de transmission de nc ?

Non, mais time ne te donne aucune garantie de ce genre non plus, donc ce
n'est pas pire.

Le plus fiable est probablement de faire la mesure côté serveur, avec
quelque chose comme :

socat tcp-listen:1234,reuseaddr exec:"dd of=/dev/null"

Il faut aussi bien faire attention à ce que le client ferme la connexion
quand il a fini, avec l'option -q 0 si on utilise nc.

On 30 Dec 2006 17:12:50 GMT, Nicolas George
<nicolas$george@salle-s.org>:

dd ne fait aucun effort pour ré-écrire la fin de ses blocs, ça fait partie
de sa spécification.

S'il affiche, à la fin, quelque chose comme
50+0 records in
50+0 records out

est-ce que ça veut dire qu'il a écrit correctement 50 blocs, ou qu'il
a envoyé partiellement 50 blocs ?

Nicolas George :

Par exemple dans un pipe, la quantité écrite sera la place restante dans
le buffer du pipe.

C'était ce que je croyais aussi, mais je suis tombé sur ça, récemment, en
préparant un sujet de TP :

Write requests to a pipe or FIFO shall be handled in the same way as a
regular file with the following exceptions:

[snip]

+ If the O_NONBLOCK flag is clear, a write request may cause the thread
to block, but on normal completion it shall return nbyte.

(man de write dans SUS3)

On peut ergoter sur le sens de « normal completion », mais ça m'a l'air de
te contredire.

Fabien LE LEZ wrote in message
<188dp2d8c1adjjkjuh3pksfi1dg7thl6f0@4ax.com>:

S'il affiche, à la fin, quelque chose comme
50+0 records in
50+0 records out

est-ce que ça veut dire qu'il a écrit correctement 50 blocs, ou qu'il
a envoyé partiellement 50 blocs ?

La première ligne dit qu'il a lu 50 blocs entiers et aucun blocs partiels,
et la seconde ligne indique la même chose pour l'écriture.