Umbral RTS, fragmentación y otras configuraciones WiFi avanzadas

Antecedentes: estoy en un entorno ruidoso y estoy tratando de optimizar mi red WiFi para tener una conexión más estable para el volumen algo elevado de usuarios (~ 50-75 en un día ocupado). Hay 4 AP, y ya he ajustado los canales y la potencia de transmisión, y en general tengo una cobertura bastante decente. Sin embargo, todavía recibo una caída de paquetes de ~ 10% cuando hago ping a Google y camino por el edificio, de itinerancia de AP a AP.

En la mayoría de los puntos de acceso WiFi que he visto, el Umbral RTS predeterminado está establecido en 2347 (por lo que he leído en varios lugares, esta configuración cuenta como "deshabilitado"), y el Umbral de fragmentación está establecido en 2346. Mi marca particular de enrutador está establecido en 2346 y 2346. Tengo varias preguntas ...

1. ¿De dónde se deriva el valor de 2346? Parece algo arbitrario, sin embargo, las notas para Frag. El umbral indica que debe ser superior a 256 y un número par.

2. Cómo están los RTS y Frag. Umbrales relacionados? Sus valores no pueden ser una coincidencia.

3. Si se modifica, ¿deberían cambiarse juntos?

4. ¿Cuál es un valor seguro para intentar reducirlos, para empezar?

Mi prioridad no es necesariamente obtener el ancho de banda máximo para cada dispositivo, sino brindar a los usuarios un ancho de banda / conexión estable y constante.

1. 2346 es el tamaño máximo de trama 802.11 . Establecer los umbrales RTS y de fragmentación al máximo significa que ningún paquete alcanzará el umbral.

2. El umbral de fragmentación limita el tamaño máximo de trama. Esto reduce el tiempo requerido para transmitir la trama y, por lo tanto, reduce la probabilidad de que se corrompa (a costa de una mayor sobrecarga de datos). El umbral RTS especifica el tamaño de trama en el que el transmisor debe usar el protocolo RTS / CTS , que es en gran parte para resolver el problema del nodo oculto . Obviamente, esto también agrega gastos generales.

3. No necesariamente: si no tiene un problema de nodo oculto, cambiar el umbral RTS no mejorará el rendimiento. Sin embargo, para que RTS / CTS ingrese el umbral de RTS debe ser igual o menor que el umbral de fragmentación.

4. Comenzaría por configurarlos de modo que una trama Ethernet estándar se fragmente en dos tramas 802.11 (1500/2 = 750 bytes de carga útil + 34 bytes de sobrecarga = 784 bytes) y cualquier trama mayor que un tercio de una trama Ethernet estándar usa RTS (534 bytes).

Sin embargo, hasta donde sé, ambas configuraciones solo afectan al transmisor, es decir, configurarlas en el AP solo hace que el AP las use para sus transmisiones y no hace que los clientes las usen para sus transmisiones.

Ese escenario mixto b / g es particularmente subóptimo. Es posible que desee revisar algunas de las discusiones anteriores sobre el tema, como:

¿El cliente inalámbrico más lento dicta la calidad de conexión de todos los demás?

Además, otro asesino de rendimiento ocurre cuando el punto A puede recibir la señal del punto B, pero B no puede recibir la señal de A. Alguien más en ServerFault señaló esto como el "efecto transmisor oculto". Más sobre ese fenómeno en el siguiente enlace. Señalan que:

"... Si bien se desea la polarización horizontal, la falta de antenas omnidireccionales comerciales polarizadas horizontalmente de bajo costo puede requerir el uso de antenas polarizadas verticalmente. Una buena antena omnidireccional polarizada verticalmente costará aproximadamente lo mismo que una antena parabólica. Uso de una antena omni-direccional ayuda a minimizar el efecto "transmisor oculto". "

http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules

No estoy de acuerdo con que "si no tiene un problema de nodo oculto, cambiar el umbral RTS no mejorará el rendimiento". El uso de CTR / RTS siempre reduce las posibilidades de colisiones de datos. Dado que cada colisión de datos causa corrupción de datos y, por lo tanto, requiere el reenvío de datos, menos colisiones significa menos reenvío de datos y menos reenvío de datos puede mejorar en gran medida su rendimiento WiFi; por supuesto solo si hay una cantidad notable de colisiones en su red.

Para explicar los detalles: un nodo siempre tiene que esperar un cierto período de tiempo y detectar el canal en busca de posibles transmisiones antes de establecer uno propio. Solo si no detecta ninguna transmisión, puede iniciar una propia. Sin RTS / CTS, esta transmisión es directamente una transmisión de datos. Si ahora dos nodos tienen la misma idea y comienzan una transmisión de datos casi al mismo tiempo, entonces estas transmisiones colisionarán. El resultado es que ninguna de las transmisiones llega a ninguna parte, ya que todos los datos recibidos se dañarán para todos los demás nodos y el AP.

Si se utiliza RTS / CTS, la transmisión comienza con un paquete RTS enviado por el nodo después de la detección. Solo si esa solicitud RTS es respondida por una respuesta CTS, se inicia una transmisión de datos. Por supuesto, si dos nodos desean transmitir al mismo tiempo, sus solicitudes de RTS también pueden colisionar con el mismo efecto negativo que no se recibe ningún RTS. La diferencia es que toda la red se recuperará mucho más rápido de una colisión RTS que de una colisión de datos. Por lo tanto, una colisión RTS es menos dañina para el rendimiento de toda la red que una colisión de datos.

La desventaja es que el RTS / CTS en sí requiere algo de ancho de banda de la red por sí solo e introduce nuevos tiempos de detección durante los cuales no se pueden realizar otras transmisiones de datos o transmisiones RTS / CTS. Para empeorar las cosas, por supuesto, RTS / CTS siempre debe realizarse utilizando la velocidad más lenta que admite la red, de lo contrario, los nodos que solo admiten esta velocidad no lo verán. Básicamente, puede decir que RTS / CTS siempre reduce el rendimiento teórico de toda su red, sin embargo, si su red sufre muchas colisiones, ya sea por el problema del nodo oculto (que también puede ser causado por nodos de otras redes que simplemente usan el mismo canal como su red) o porque su WiFi está abarrotado (a medida que más nodos aumentan la posibilidad de colisiones aleatorias), de hecho, puede aumentar el rendimiento real. No es el número de nodos ocultos,

Leí un estudio (actualizaré y agregaré un enlace aquí una vez que pueda encontrarlo nuevamente), que sugiere que a menos que su red sea realmente pequeña (menos de tal vez 6 nodos y cubra solo un área pequeña) y no esté aislada de otros redes que usan el mismo canal, el uso de RTS / CTS casi siempre tiene un efecto bastante positivo en la práctica. Entonces, ¿por qué el valor umbral? Si enviar los datos llevaría tanto tiempo como lo haría un apretón de manos RTS / CTS, hay poco beneficio al usar RTS / CTS, ya que si la red tiene que recuperarse de una colisión de datos muy pequeña o de una colisión RTS no mucha diferencia La mejor recuperación de las colisiones RTS se debe a que los paquetes RTS son muy pequeños, mientras que los paquetes de datos generalmente no lo son. Pero para paquetes de datos muy pequeños, RTS / CTS solo agrega gastos generales sin ganancia práctica.

Y ahora también sabe cómo un umbral de fragmentación puede mejorar el rendimiento de la red. Por un lado, limita el tamaño de los paquetes enviados y, como se explicó anteriormente, cuanto más pequeño es el paquete en una colisión, más rápido se recuperará la red. Y, por otro lado, si hubo una colisión, solo el fragmento afectado debe ser reenviado, no todo el paquete. Sin embargo, cada fragmento enviado tiene una sobrecarga propia, por lo que cuantos más fragmentos se envíen, más sobrecarga se agregará y sobrecarga es básicamente un ancho de banda desperdiciado que también podría haberse utilizado para las transmisiones de datos.