Seuil RTS, fragmentation et autres paramètres WiFi avancés
Contexte: Je suis dans un environnement bruyant et j'essaie d'optimiser mon réseau WiFi pour avoir une connexion plus stable pour le volume quelque peu élevé d'utilisateurs (~ 50-75 par une journée chargée). Il y a 4 points d'accès, et j'ai déjà ajusté les canaux et la puissance de transmission, et dans l'ensemble j'ai une couverture assez décente. Cependant, j'obtiens toujours environ ~ 10% de perte de paquets lorsque j'effectue un ping sur Google et que je me promène dans le bâtiment, en itinérance d'un point d'accès à un point d'accès.
Dans la plupart des points d'accès WiFi que j'ai vus, le seuil RTS par défaut est défini sur 2347 (d'après ce que j'ai lu à divers endroits, ce paramètre compte comme "désactivé"), et le seuil de fragmentation est défini sur 2346. Ma marque particulière de routeur est fixé à 2346 et 2346. J'ai plusieurs questions ...
D'où dérive la valeur de 2346? Il semble cependant quelque peu arbitraire, les notes de Frag. Le seuil indique qu'il doit être supérieur à 256 et un nombre pair.
Comment sont les RTS et Frag. Seuils liés? Leurs valeurs ne peuvent pas être une coïncidence.
S'ils sont modifiés, doivent-ils être changés ensemble?
Quelle est une valeur sûre pour essayer de les réduire, pour commencer?
Ma priorité n'est pas nécessairement d'obtenir une bande passante de pointe pour chaque appareil, mais de donner aux utilisateurs une bande passante/connexion stable et cohérente.
2346 est la taille maximale trame 802.11 . La définition des seuils RTS et de fragmentation au maximum signifie qu'aucun paquet ne respectera le seuil.
Le seuil de fragmentation limite la taille d'image maximale. Cela réduit le temps requis pour transmettre la trame, et par conséquent réduit la probabilité qu'elle soit corrompue (au prix d'une surcharge de données). Le seuil RTS spécifie la taille de trame à laquelle l'émetteur doit utiliser le protocole RTS/CTS , qui est en grande partie pour résoudre le problème de nœud caché . Cela ajoute évidemment aussi des frais généraux.
Pas nécessairement - si vous n'avez pas de problème de nœud caché, la modification du seuil RTS n'améliorera pas les performances. Pour que RTS/CTS entame le seuil RTS, il doit être identique ou inférieur au seuil de fragmentation.
Je commencerais par les définir de telle sorte qu'une trame Ethernet standard soit fragmentée en deux trames 802.11 (1500/2 = 750 octets de charge utile + 34 octets de surcharge = 784 octets) et toutes les trames supérieures à un tiers d'une trame Ethernet standard utilisent RTS (534 octets).
Pour autant que je sache, ces deux paramètres n'affectent que l'émetteur, c'est-à-dire que leur configuration sur l'AP ne fait que l'AP les utiliser pour ses transmissions et ne fait pas que les clients les utilisent pour leurs transmissions.
Ce scénario mixte b/g est particulièrement sous-optimal. Vous voudrez peut-être revoir certaines des discussions précédentes sur le sujet, telles que:
Le client sans fil le plus lent dicte la qualité de connexion de tous les autres?
En outre, un autre tueur de performances se produit lorsque le point A peut recevoir le signal du point B, mais que B ne peut pas recevoir le signal de A. Quelqu'un d'autre sur ServerFault l'a signalé comme "l'effet d'émetteur caché". Plus d'informations sur ce phénomène sur le lien ci-dessous. Ils soulignent que:
"... Bien que la polarisation horizontale soit souhaitée, le manque d'antennes commerciales omnidirectionnelles polarisées horizontalement peu coûteuses peut nécessiter l'utilisation d'antennes polarisées verticalement. Une bonne antenne omnidirectionnelle polarisée verticalement coûtera environ le même prix qu'une antenne parabolique. L'utilisation d'une antenne omnidirectionnelle permet de minimiser l'effet "émetteur caché". "
http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules
Je ne suis pas d'accord sur le fait que "si vous n'avez pas de problème de nœud caché, la modification du seuil RTS n'améliorera pas les performances". L'utilisation de CTR/RTS réduit toujours les risques de collisions de données. Étant donné que chaque collision de données entraîne une corruption des données et nécessite donc la retransmission des données, moins de collisions signifie moins de réexpédition de données et moins de réexpédition de données peut grandement améliorer vos performances WiFi; bien sûr seulement s'il y a une quantité notable de collisions dans votre réseau.
Pour expliquer les détails: Un nœud doit toujours attendre une certaine période de temps et détecter le canal pour d'éventuelles transmissions avant d'en déclarer un propre. Seulement s'il ne détecte aucune transmission, il peut en démarrer une propre. Sans RTS/CTS, cette transmission est directement une transmission de données. Si maintenant deux nœuds ont la même idée et commencent une transmission de données presque en même temps, alors ces transmissions entreront en collision. Le résultat est que ni l'une ni l'autre des transmissions ne se fait nulle part car toutes les données reçues seront corrompues pour tous les autres nœuds et l'AP.
Si RTS/CTS est utilisé, la transmission commence par l'envoi d'un paquet RTS par le nœud après la détection. Ce n'est que si cette demande RTS reçoit une réponse CTS qu'une transmission de données est lancée. Bien sûr, si deux nœuds veulent transmettre en même temps, leurs demandes RTS peuvent également entrer en collision avec le même effet négatif qu'aucun RTS n'est reçu du tout. La différence est que l'ensemble du réseau se rétablira beaucoup plus rapidement d'une collision RTS que d'une collision de données. Ainsi, une collision RTS est moins préjudiciable à l'ensemble des performances du réseau qu'une collision de données.
L'inconvénient est que RTS/CTS lui-même nécessite une certaine bande passante réseau et introduit de nouveaux temps de détection pendant lesquels aucune autre transmission de données ou transmission RTS/CTS ne peut avoir lieu. Pour aggraver les choses, bien sûr, RTS/CTS doit toujours être effectué en utilisant la vitesse la plus lente prise en charge par le réseau, sinon les nœuds ne prenant en charge que cette vitesse ne la verront pas. Donc, fondamentalement, vous pouvez dire que RTS/CTS réduit toujours le débit théorique de tout votre réseau, mais si votre réseau souffre de nombreuses collisions, soit par le problème de nœud caché (qui peut également être causé par des nœuds d'autres réseaux utilisant simplement le même comme votre réseau) ou parce que votre WiFi est encombré (car plus de nœuds augmentent les risques de collisions aléatoires), cela peut en fait augmenter le débit réel. Pas le nombre de nœuds cachés, le nombre de collisions est le facteur important ici, quelle que soit la façon dont elles sont causées.
J'ai lu une étude (je mettrai à jour et ajouterai un lien ici une fois que j'aurai pu le retrouver), qui suggère qu'à moins que votre réseau soit vraiment petit (moins de peut-être 6 nœuds et ne couvrant qu'une petite zone) et non isolé des autres les réseaux utilisant le même canal, l'utilisation de RTS/CTS a presque toujours un effet plutôt positif dans la pratique. Alors pourquoi la valeur seuil? Si l'envoi des données prendrait autant de temps qu'une prise de contact RTS/CTS, il y a peu de gain à utiliser RTS/CTS, car si le réseau doit se remettre d'une très petite collision de données ou d'une collision RTS ne fera pas beaucoup de différence. La meilleure récupération après les collisions RTS est due au fait que les paquets RTS sont très petits alors que les paquets de données ne le sont généralement pas. Mais pour les très petits paquets de données, RTS/CTS ajoute simplement une surcharge sans gain pratique.
Et maintenant, vous savez également comment un seuil de fragmentation peut améliorer les performances du réseau. D'une part, il limite la taille des paquets envoyés et, comme expliqué ci-dessus, plus le paquet lors d'une collision est petit, plus le réseau s'en remettra rapidement. Et d'autre part, en cas de collision, seul le fragment affecté doit être renvoyé, pas le paquet entier. Cependant, chaque fragment envoyé a une surcharge qui lui est propre, donc plus il y a de fragments envoyés, plus la surcharge qui s'ajoutera et la surcharge est essentiellement une bande passante gaspillée qui aurait également pu être utilisée pour les transmissions de données.