Предыстория: я нахожусь в шумной обстановке, и я пытаюсь оптимизировать свою сеть Wi-Fi, чтобы иметь более стабильное соединение для довольно большого количества пользователей (~ 50-75 в загруженный день). Есть 4 точки доступа, я уже настроил каналы и мощность передачи, и в целом у меня довольно приличное покрытие. Тем не менее, я все еще получаю около 10% падения пакетов при пинге в Google и хождении по зданию, перемещаясь от AP к AP.
В большинстве точек доступа Wi-Fi, которые я видел, порог RTS по умолчанию установлен на 2347 (из того, что я читал в разных местах, этот параметр считается "отключенным"), а порог фрагментации установлен на 2346. Моя конкретная марка маршрутизатора установлен на 2346 и 2346. У меня есть несколько вопросов ...
Откуда взялось значение 2346? Однако примечания для Frag. Пороговое значение указывает, что оно должно быть больше 256 и четное число.
Как RTS и Frag. Пороги связаны? Их ценности не могут быть совпадением.
В случае изменения следует ли их менять вместе?
Какое безопасное значение для начала стоит попробовать снизить?
Моим приоритетом не обязательно является получение максимальной пропускной способности для каждого устройства, но предоставление пользователям стабильной и согласованной пропускной способности / соединения.
2346 - это максимум Рамка 802.11 размер. Установка максимальных порогов RTS и фрагментации означает, что ни один пакет не будет соответствовать пороговому значению.
Порог фрагментации ограничивает максимальный размер кадра. Это сокращает время, необходимое для передачи кадра, и, следовательно, снижает вероятность того, что он будет поврежден (за счет дополнительных накладных расходов). Порог RTS определяет размер кадра, при котором передатчик должен использовать RTS / CTS протокол, который в основном предназначен для решения проблема со скрытым узлом. Это, очевидно, также увеличивает накладные расходы.
Не обязательно - если у вас нет проблемы со скрытым узлом, изменение порога RTS не улучшит производительность. Однако для того, чтобы RTS / CTS сработал, порог RTS должен быть таким же или меньше порога фрагментации.
Я бы начал с их настройки так, чтобы стандартный кадр Ethernet был фрагментирован на два кадра 802.11 (1500/2 = 750 байтов полезной нагрузки + 34 байта служебных данных = 784 байта), а любые кадры, превышающие треть стандартного кадра Ethernet, использовали RTS (534 байта). байтов).
Насколько мне известно, обе эти настройки влияют только на передатчик, то есть настройка их на AP только заставляет AP использовать их для своих передач и не заставляет клиентов использовать их для своих передач.
Этот смешанный сценарий b / g особенно неоптимален. Вы можете просмотреть некоторые из предыдущих обсуждений этой темы, например:
Самый медленный беспроводной клиент определяет качество соединения всех остальных?
Кроме того, еще один фактор, снижающий производительность, возникает, когда точка 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 всегда снижает теоретическую пропускную способность всей вашей сети, однако, если ваша сеть страдает от большого количества конфликтов, либо из-за проблемы со скрытым узлом (которая также может быть вызвана узлами из других сетей, просто использующих то же канал в качестве вашей сети) или из-за того, что ваш Wi-Fi переполнен (поскольку большее количество узлов увеличивает вероятность случайных конфликтов), это может фактически увеличить фактическую пропускную способность. Здесь важным фактором является не количество скрытых узлов, а количество столкновений, независимо от того, как они вызваны.
Я прочитал исследование (я обновлю и добавлю сюда ссылку, как только смогу найти ее снова), в котором говорится, что если ваша сеть не очень мала (менее 6 узлов и покрывает только небольшую площадь) и не изолирована от других сети, использующие один и тот же канал, использование RTS / CTS практически всегда дает довольно положительный эффект на практике. Так почему же пороговое значение? Если отправка данных займет столько же времени, сколько потребуется рукопожатие RTS / CTS, от использования RTS / CTS мало пользы, поскольку восстановление сети после очень небольшого конфликта данных или из-за конфликта RTS не повлияет. большая разница. Лучшее восстановление после коллизий RTS заключается в том, что пакеты RTS очень малы, тогда как пакеты данных обычно нет. Но для очень маленьких пакетов данных RTS / CTS просто увеличивает накладные расходы без практической выгоды.
И теперь вы также знаете, как порог фрагментации может улучшить производительность сети. С одной стороны, он ограничивает размер отправляемых пакетов, и, как объяснялось выше, чем меньше размер пакета в конфликте, тем быстрее сеть восстановится после него. И с другой стороны, если произошла коллизия, необходимо повторно отправить только затронутый ею фрагмент, а не весь пакет. Однако каждый отправленный фрагмент имеет свои собственные накладные расходы, поэтому чем больше отправляется фрагментов, тем больше накладных расходов, которые будут добавлены, и накладные расходы, по сути, являются потраченной впустую полосой пропускания, которую также можно было бы использовать для передачи данных.