> classiques ? Meme des paquets de 1500 bytes me semblent trop gros pour
> ces vitesses... Peut-etre ok lorsque l'on est seul a faire un ftp mais
> pas vraiment aproprie lorsqu'il y a plusieurs process communicants sur
> la ligne. Certe le throughput est globalement meilleur mais le temps de
C'est bien ça:
- gros MTU: efficacité meilleure (chaque paquet IP a un poids, sauf
erreur environ 28 bytes, cf sizeof(iphdr), faut encore ajouter
les headers TCP, et probablement on arrive à 50 bytes. Donc
si tu as un MTU de 250, tu perdras 20% sur la bande passante de
ton modem (à peut près ce que tu gagnes par la conversion synchrone
de 2 bits sur 10 sans le framing).
- petit MTU: interactivité meilleure. On ne doit attendre que
MTU bytes au maximum pour pouvoir émettre.
Exemple: MTU de 1000 sur une liaison PPP à 28'800 bps (donc
disons 3000 cps), en interactif (telnet) il faudra
donc attendre au plus 2 * 1/3 de secondes, soit
600 ms pour avoir l'écho de ses caractères en telnet
(le NAG algorithm, qui va grouper les caractères va
donc provoquer un effet de saccades, mais rendre la
chose relativement utilisable. Sans NAG ça va être
insupportable).
Bien sûr, sans trafic sur la liaison, le MTU n'a aucune importance.
L'importance arrive dès que tu fais p.ex. du FTP simultanément
à du telnet ou SSH.
A cela s'ajoute, sans MTU discovery, le fait que plus le MTU est gros,
plus il y a risque de fragmentation et donc de pertes de paquets baissant
la performance.
NB: on peut changer le MTU dynamiquement (ifconfig ppp0 mtu 300)
suivant ce qu'on fait.
> reponse des petites transactions est moins bon lorsqu'il y a un mix avec
> d'autres gros transferts.
> PS: Promis, je ne pose plsu de questions a ce propos :-)
Les bonnes questions ne sont pas forcément celles auxquelles une réponse
est facilement trouvée :)
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
