Порог RTS, фрагментация и другие расширенные настройки WiFi

Предыстория: я нахожусь в шумной обстановке, и я пытаюсь оптимизировать свою сеть WiFi, чтобы иметь более стабильное соединение для довольно большого количества пользователей (~ 50-75 в напряженный день). Есть 4 точки доступа, и я уже настроил каналы и мощность передачи, и в целом у меня достаточно приличное покрытие. Тем не менее, я все равно получаю около 10% пропадания пакетов при пинге Google и обходе здания, роуминг от точки доступа к точке доступа.

В большинстве точек доступа WiFi, которые я видел, порог RTS по умолчанию установлен на 2347 (из того, что я читал в разных местах, этот параметр считается «отключенным»), а порог фрагментации установлен на 2346. Мой конкретный бренд маршрутизатора установлен на 2346 и 2346. У меня есть несколько вопросов ...

1. Откуда взято значение 2346? Это кажется несколько произвольным, однако, заметки для Frag. Порог указывает, что он должен быть больше 256 и четное число.

2. Как работают RTS и Frag. Пороги связаны? Их значения не могут быть совпадением.

3. Если они изменены, должны ли они быть изменены вместе?

4. Какое безопасное значение, чтобы попытаться снизить их, для начала?

Моим приоритетом является не обязательно получение максимальной пропускной способности для каждого устройства, но предоставление пользователям стабильной, стабильной пропускной способности / соединения.

1. 2346 - максимальный размер кадра 802.11 . Установка RTS и порогов фрагментации на максимум означает, что ни один пакет не будет соответствовать порогу.

2. Порог фрагментации ограничивает максимальный размер кадра. Это уменьшает время, необходимое для передачи кадра, и, следовательно, уменьшает вероятность его повреждения (за счет увеличения объема данных). Порог RTS определяет размер кадра, при котором передатчик должен использовать протокол RTS / CTS , который в значительной степени решает проблему скрытого узла . Это, очевидно, также добавляет накладные расходы.

3. Не обязательно - если у вас нет проблемы со скрытыми узлами, изменение порога RTS не приведет к повышению производительности. Для того чтобы RTS / CTS выдвинули порог RTS, он должен быть таким же или меньшим, чем порог фрагментации.

4. Я бы начал с их установки таким образом, чтобы стандартный кадр Ethernet был фрагментирован на два кадра 802.11 (1500/2 = 750 байт полезной нагрузки + 34 байта служебных данных = 784 байта), и любые кадры, превышающие треть стандартного кадра Ethernet, используют RTS (534 байт).

Насколько мне известно, обе эти настройки влияют только на передатчик, то есть их настройка на AP только заставляет AP использовать их для своих передач и не заставляет клиентов использовать их для своих передач.

Этот смешанный сценарий б / г является особенно неоптимальным. Вы можете рассмотреть некоторые из предыдущих обсуждений по этой теме, такие как:

Самый медленный беспроводной клиент диктует качество связи всех остальных?

Кроме того, другой убийца производительности происходит, когда точка A может получить сигнал точки B, но B не может получить сигнал A. Кто-то еще на ServerFault указал на это как «скрытый эффект передатчика». Подробнее об этом явлении по ссылке ниже. Они указывают, что:

»... В то время как горизонтальная поляризация желательно, отсутствие недорогих коммерческих горизонтально поляризованных всенаправленные антенны может потребоваться использование вертикально поляризованных антенн. Хороший всенаправленный вертикально поляризованной антенны будет стоить примерно такой же , как параболической антенны. Использование всенаправленная антенна позволяет свести к минимуму эффекта «скрытый передатчик». "

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

Я не согласен с тем, что «если у вас нет проблемы со скрытыми узлами, изменение порога RTS не приведет к повышению производительности». Использование CTR / RTS всегда снижает вероятность столкновения данных. Поскольку каждое столкновение данных приводит к повреждению данных и, следовательно, требует повторной отправки данных, меньшее количество конфликтов означает, что меньшая повторная отправка данных и меньшая повторная отправка данных могут в значительной степени улучшить вашу производительность WiFi; конечно, только если в вашей сети есть заметные коллизии.

Чтобы объяснить детали: узел всегда должен ждать определенный период времени и определять канал на предмет возможных передач, прежде чем указывать собственную передачу. Только если он не чувствует никаких передач, он может начать собственную. Без RTS / CTS эта передача напрямую является передачей данных. Если теперь оба узла имеют одну и ту же идею и начинают передачу данных почти одновременно, то эти передачи будут конфликтовать. Результатом является то, что ни одна передача не происходит нигде, поскольку все полученные данные будут повреждены для всех других узлов и точки доступа.

Если используется RTS / CTS, передача начинается с пакета RTS, отправляемого узлом после обнаружения. Только если на этот запрос RTS получен ответ CTS, начинается передача данных. Конечно, если два узла хотят передавать одновременно, их запросы RTS также могут сталкиваться с тем же отрицательным эффектом, что RTS вообще не принимается. Разница в том, что вся сеть будет восстанавливаться намного быстрее от коллизии RTS, чем от коллизии данных. Таким образом, коллизия RTS менее вредна для всей производительности сети, чем коллизия данных.

Недостатком является то, что RTS / CTS сама по себе требует некоторой полосы пропускания сети сама по себе, и она вводит новые времена обнаружения во время, когда никакие другие передачи данных или передачи RTS / CTS не могут иметь место. Что еще хуже, конечно, RTS / CTS всегда должен выполняться с использованием самой низкой скорости, поддерживаемой сетью, иначе узлы, поддерживающие только эту скорость, не увидят ее. Таким образом, в основном вы можете сказать, что RTS / CTS всегда снижает теоретическую пропускную способность всей вашей сети, однако, если ваша сеть страдает от множества коллизий, либо из-за проблемы со скрытыми узлами (которая также может быть вызвана узлами из других сетей, использующими одни и те же канал как ваша сеть), или потому что ваш WiFi перегружен (так как больше узлов увеличивает вероятность случайных коллизий), это может фактически увеличить фактическую пропускную способность. Не количество скрытых узлов,

Я читаю исследование (я обновлю и добавлю сюда ссылку, как только смогу найти ее снова), в которой говорится, что если ваша сеть не очень мала (менее 6 узлов и охватывает только небольшую область) и не изолирована от других В сетях, использующих один и тот же канал, использование RTS / CTS практически всегда имеет довольно положительный эффект на практике. Так почему пороговое значение? Если отправка данных займет столько же времени, сколько и подтверждение RTS / CTS, использование RTS / CTS дает мало пользы, поскольку необходимость восстановления сети после очень маленького конфликта данных или из-за конфликта RTS не повлияет большая разница Лучшее восстановление после коллизий RTS связано с тем, что пакеты RTS очень малы, а пакеты данных обычно - нет. Но для очень маленьких пакетов данных RTS / CTS просто добавляет издержки без практической выгоды.

И теперь вы также знаете, как порог фрагментации может улучшить производительность сети. С одной стороны, это ограничивает размер отправляемых пакетов, и, как объяснено выше, чем меньше пакет при коллизии, тем быстрее сеть восстановится после него. А с другой стороны, если произошла коллизия, необходимо переслать только затронутый ею фрагмент, а не весь пакет. Однако каждый отправленный фрагмент имеет собственные издержки, поэтому, чем больше отправляемых фрагментов, тем больше накладных расходов, которые будут добавлены, а издержки - это, в основном, потраченная впустую полоса пропускания, которая также могла бы быть использована для передачи данных.