[Ran] Microcoupures...

Michel Roche listes.pichel at free.fr
Mar 31 Mar 20:22:12 CEST 2009


Bonsoir, et merci pour vos réponses.

@Fred : le MTU de mon modem est bien à 1492, celui des utilisateurs  
également (j'ai pas vérifié pour tous d'ailleurs, mais j'ai fait des  
tests moi avec une MTU à 1492 de sûr)

Le 26 mars 09 à 19:56, Attila a écrit :

> Salut,
>
> Je rencontre aussi des coupures, plus ou moins importantes selon  
> l'emplacement sur le réseau (qui comporte plusieurs relais), et  
> malgré le réglage du MTU. La seule solution que j'ai trouvé est  
> d'utiliser FDM (FreeDownloadManager). J'ai pu observer que certains  
> browser sont plus sensibles que d'autres ! J'en ai conclue que cela  
> venait probablement d'un timeout quelque-part, mais je ne sais pas où.

Certains logiciels sont effectivement plus sensibles que d'autres au  
problème : wget marche beaucoup mieux que Firefox, certains clients  
FTP mieux que d'autres par exemple.

Mais ça ne m'enlève pas l'épine du pied :-)

Je constate ceci sur mon lien principal, celui qui ramasse tout le  
débit du réseau, ainsi que sur d'autres AP (même si les compteurs vont  
forcément moins vite sur ceux-ci) : Il y a une proportion assez  
importantes d'acquittements qui sont perdus (ACK failed).
Làn sur 20000 trames j'en ai déjà 600 (lu sur les compteurs de l'AP,  
un Alvarion - j'avais déjà constaté avec Wireshark), ça fait tout de  
même du 3 % ! Ça entraîne inévitablement des duplications de trames,  
puisque les non acquittées sont renvoyées.
Du côté des erreurs de CRC, ça se situe de façon assez stable entre 1  
et 3 % aussi, ça joue sans doute également... mais je ne vois pas bien  
que faire sur ce point lorsque les liens radio sont entre -66 et -71 dB.

Ce nombre assez important d'acquittements non reçus à temps entraîne  
forcément pas mal de réémissions, et plombe les logiciels qui pour  
finir pensent avoir perdu leur connexion. Enfin, c'est comme ça que  
j'analyse la situation...

J'ai tenté d'augmenter le réglage de la distance entre APs, j'ai même  
mis jusqu'à 25 km (c'est même pas vrai que mes liens soient aussi  
longs !), de façon à ce que les appareils attendent plus longtemps  
pour recevoir leur ACK, mais ça ne change pas vraiment la donne...  
encore que ça aurait l'air de se stabiliser à un gros pourcent de ACKs  
non reçus. Je vais attendre de voir ce que les utilisateurs ressentent.

Dans les autres paramètres à tripoter, je ne sais pas trop quoi  
essayer :
- Prémbule court -> rien  à voir je pense
- CW (fenêtre de contention) : je pourrais peut-être tenter  
d'augpmenter le minimum de façon à ce que l'attente avant nouvel essai  
soit plus longue et espérer moins d'erreurs, ou bien raisonner à  
l'inverse et la diminuer de façon à ce que les réexpéditions soient  
optimisées, au moins la première ?
- Abaisser le seuil de RTS de façon à ce que les clients demandent  
l'autorisation plus tôt avant d'envoyer. Actuellement le seuil est à  
2347 et manifestement les demandes de RTS/CTS restent à zéro sur l'AP.  
Autant dire que ce mode de réservation est désactivé. Mais vu la  
situation actuelle, je me demande si ça ne vaudrait pas le coup de  
payer un peu de bande passante contre moins d'erreurs...
- J'ai également deux champs "Short retry limit" et "Long retry  
limit" : réglés respectivement à 7 et 4. C'est le nombre d'essais  
autorisés pour les paquets < au seuil RTS et > à ce seuil. Mo problème  
se situe un peu avant je crois : j'aimerais bien éviter ces  
réémissions :-)






More information about the Ran mailing list