Содержание
Привет, всем! И сегодня у нас будет очень интересная тема. В частности, мы поговорим про более точную настройку Wi-Fi на маршрутизаторе. Обычно ведь как бывает – человек заходит, меняет имя беспроводной сети, устанавливает ключ и уходит. И этого вполне хватает, но некоторых не совсем хватает скорости передачи данных в беспроводном пространстве. И вот тут начинаются танцы с бубном и не только.
А началось с того, что ко мне опять пришло очень интересное письмо: «Short GI в Wi-Fi – что это и для чего нужно?». Если вы читаете эти строки, то скорее всего вы залезли под капот WiFi модуля в настройки маршрутизатора и увидели непонятные параметры. При этом вы можете видеть вот такое окошко.
Пояснения
И так начнем, наверное, с Short GI или Short Guard Interval (короткий защитный интервал). Это специальный интервал между поочередно передаваемыми пакетами данных. То есть маршрутизатор отправляет на компьютер определенный пакет, так вот, прежде чем отправлять следующие данные, выжидается определенное время.
Стандартное значение 800нс. Но если включить Short GI – это значение будет вдвое меньше, то есть информация передаваться будет куда быстрее. Конечно в теории такое быть может, но иногда бывает, что при включении данной функции скорость наоборот падает. Все дело в том, что при значении 800 нс, данные отправляются, а ещё приходит обратный ответ, что все данные дошли в сохранности. А за 400нс компьютер может из-за помех принять данные с ошибкой и отправить сигнал обратно, но ему прилетит следующий пакет. В итоге компьютеру нужно будет ждать, пока маршрутизатор не отправит прошлый пакет.
Помехи возникают от других источников радиочастот – в частности от соседских роутеров, которые работают на той же частоте. Поэтому тут нужно просто экспериментировать. Попробуйте включить данную функцию и протестировать скорость интернета на конечном устройстве. Если скорость упадет — значит вам мешают соседские роутеры, которые глушат сигнал.
Следующий параметр — это «Интервал маяка» (Beacon Interval) или «Сигнальный интервал». По стандарту обычно стоит значение в 100 миллисекунд. Данная функция определяет как часто от роутера идёт сигнальный пакет к конечному клиенту. Тут можно установить значение и в 50, если вы постоянно ходите по квартире с телефоном. Это нужно, чтобы роутер как можно чаще с вами связывался. Для обычного стационарного компьютера или ноутбука – значения 100 будет достаточно.
Порог RTS — это значение максимального размера пакета. То есть какой максимальный пакет должны по размеру отправляться за раз. Если пакет будет больше данного значения, то данные будут отправлены на специальную принимающую станцию. Также отправка пакетов будет постоянно согласоваться с двумя устройствами. Стандартный размер 2346, на самом деле это оптимальный вариант и больше ставить нельзя, так как конечный клиент может не смочь принять такой большой пакет. Если поставить наоборот меньше, то могут возникнуть трудности, так как пакетов будет слишком много, и они все будут отлеживаться при передаче в конце пути.
Порог фрагментации — это максимальный размер, после которого пакет будет фрагментирован или разделен на части. Данное значение устанавливается такое же, как на пороге RTS.
Интервал DTIM — это временный интервал, после которого все пакеты, находящиеся в буфере, будут отправлены клиенту. Самый лучший вариант — это 1. Если установить значение больше, то пакеты будут простаивать и просиживать в буфере. При этом немного экономится электроэнергия. Если установить слишком большое значение некоторые пакеты могут быть потеряны.
3 ответа
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 указал на это как «скрытый эффект передатчика». Подробнее об этих явлениях по ссылке ниже. Они указывают, что:
". Если требуется горизонтальная поляризация, отсутствие недорогих коммерческих горизонтально поляризованных всенаправленных антенн может потребовать использования антенн с вертикальной поляризацией. Хорошая всенаправленная вертикально поляризованная антенна будет стоить примерно так же, как параболическая антенна . Использование всенаправленной антенны помогает минимизировать эффект «скрытого передатчика». "
Я не согласен с тем, что «если у вас нет проблемы с скрытым узлом, тогда изменение порога 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 просто добавляет накладные расходы без практического выигрыша.
И теперь вы также знаете, как порог фрагментации может улучшить производительность сети. С одной стороны, он ограничивает размер отправленных пакетов и, как объяснялось выше, чем меньше пакет при столкновении, тем быстрее сеть восстанавливается из него. И, с другой стороны, если произошло столкновение, необходимо повторно отправить только фрагмент, на который он был направлен, а не весь пакет. Тем не менее, каждый отправленный фрагмент имеет собственные накладные расходы, поэтому чем больше фрагментов отправляется, тем больше накладных расходов, которые будут добавляться и накладные расходы, в основном направляется в полосу пропускания, которая также могла использоваться для передачи данных.
Основная задача эксперимента — заставить точку доступа НОРМАЛЬНО жить с "специфическим" оборудованием, не работающим с ДЕФОЛТОВЫМИ настройками. В то время мой Samsung Galaxy Note и другие устройства в т.ч. и Айфоны и некоторые айпады так же работали без проблем. Вероятно это индивидуальный глюк некоторых устройств на апаратном или програмном уровне, но в данном случае удалось одновременно и исправить глюк лёгкой настройкой точки доступа и заодно оптимизировать работу WiFi для случая тяжёлых файлов.
UPD:
RTS Threshold (Пороговое значение RTS): RTS Threshold (Пороговое значение RTS) — это минимальное число байт, для которого может действовать механизм соединения по каналу с использованием сигналов готовности к передаче/готовности к приему (RTS/CTS). В сети с высоким уровнем радиочастотных помех или большим числом беспроводных устройств, использующих один и тот же канал, снижение значения RTS Threshold (Пороговое значение RTS) может способствовать сокращению числа потерянных фреймов. Пороговое значение RTS по умолчанию составляет 2347 байт; это максимально возможное значение.
Fragmentation threshold (Порог фрагментации): Это максимальное значение, доступное для маршрутизатора при отправке информации в пакетах, прежде чем пакеты будут разбиты на фрагменты. Обычно причинами проблем, возникающих при отправке информации, являются наличие другого сетевого трафика и конфликты передаваемых данных. Их можно устранить, разбив информацию на фрагменты. Чем ниже установленный порог фрагментации, тем меньше размер пакета, который не будет разбиваться на фрагменты. При максимальном значении (2346) фрагментация практически отключается. Изменять данное значение могут только опытные пользователи.
UPD2:
Заметку написал потому, что тут и на других Маководовских форумах было много криков насчёт глюков совместимости точек доступа и ВиФи роутеров с Маковским железом. У меня был наглядный пример — 2 одинаковых iPad с одинаковыми прошивками — один мгновенно подключился в моему ВиФи, а другой замупил и не подключился. Поскольку у меня лично нет Маковского железа, а работаю с железками юзверей, которые их не всегда и в руки то дают потискать — пришлось изучать матчасть по форумам и первоначально решил проблему отключением режима 40мегабит передачи, а в случае с Dell вообще отключение N-протокола, а уже потом поскольку с Dell была возможность поиграться — нашёл указанные выше параметры и теперь всё работает с максимально возможными скоростями(Dell пишет 150мегабит, а точка о этом соединении пишет 108мегабит к клиенту и 56мегабит от клиента).
Загрузка...
