Les lignes lentes (à faible débit) comprennent les modems, RNIS et aussi sans doute les autres connexions longue distance.
Cette section est basée sur la connaissance des protocoles utilisés mais pas sur des expérimentations. Faites moi savoir si vous essayez ceci ;-)
La première chose à retenir est que NFS est un protocole lent. Il a un grand overhead (sur-coût en bande passante). Utiliser NFS, c'est presque comme utiliser kermit pour transférer des fichiers. Il est lent. Presque tout est plus rapide que NFS. FTP est plus rapide. HTTP est plus rapide. rcp est plus rapide. ssh est plus rapide.
Vous voulez toujours l'essayer ? Ok.
Par défaut NFS est paramétré pour des lignes rapides et à faible latence. Si vous utilisez les paramètres par défaut sur des lignes à grande latence cela peut provoquer des erreurs, des annulations, des rétrécissements de fichiers, et des comportements bizarres.
La première chose à faire est de ne pas utiliser l'option de montage
soft. Les temporisations retourneront des erreurs au logiciel, qui, dans
l'immense majorité des cas, ne saura pas quoi en faire. C'est une bonne
façon d'avoir des problèmes bizarres. Utilisez plutôt l'option de montage
hard. Quand hard est actif les temporisations déclenchent des
essais infinis au lieu d'annuler ce que le logiciel était en train de
faire (quoi que ce soit). C'est ce que vous voulez. Vraiment.
La deuxième chose à faire est d'ajuster les options de montage timeo
et retrans. Elles sont décrites dans la page de manuel nfs(5), en voici
un extrait (version française) :
timeo=n La valeur, en dixiemes de secondes, du
delai avant de declencher la premiere
retransmission d'une RPC. La valeur par
defaut est 7/10 de seconde. Apres une pre
miere expiration, le delai est double et
l'on recommence les retransmissions jusqu'a
ce que le delai atteigne la valeur maximale
de 60 secondes, ou que le nombre maximal de
retransmission soit depasse. Il se produit
alors une erreur d'expiration majeure de
delai. Si le systeme est monte "en dur",
les retransmissions reprendront a nouveau
indefiniment.
On peut ameliorer les performances en aug
mentant le delai sur un reseau charge, si
le serveur est un peu lent, ou si l'on
traverse plusieurs routeurs ou passerelles.
retrans=n Le nombre d'expirations mineures et de
retransmissions qui doivent se produire
avant de declencher une expiration majeure.
La valeur par defaut est 3 expirations
mineures. Quand une erreur d'expiration
majeure se produit, soit l'operation est
abandonnee, soit un message "server not
responding" est affiche sur la console.
En d'autres mots : si une réponse n'est pas reçue avant la temporisation de 0,7 seconde (700 ms), le client NFS répétera la requête et doublera la temporisation à 1,4 seconde. Si la réponse n'arrive pas dans les 1,4 seconde, la requête est répétée à nouveau et la temporisation est doublée à 2,8 secondes.
La vitesse de la ligne peut être mesurée avec un ping ayant vos valeurs de rsize/wsize comme taille de paquet.
$ ping -s 8192 lugulbanda PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes 8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms 8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms 8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms --- lugulbanda.uio.no ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 14.9/15.1/15.9 ms
Le temps indiqué est celui que le paquet du ping a pris pour aller et
revenir de lugulbanda. 15 ms, c'est assez rapide. Sur une ligne à 28 800 bps
vous pouvez vous attendre à une valeur de l'ordre de 4000-5000 ms, et si la
ligne est chargée ce temps sera encore plus élevé, facilement le double. En
général, la latence augmente avec la taille des paquets et la charge de la
ligne. Si vous comptez utiliser FTP et NFS en même temps il faudra mesurer
les temps du ping pendant un transfert FTP et augmenter timeo en accord
avec la latence de votre ligne.