Поріг RTS, фрагментація та інші розширені налаштування Wi-Fi

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

У більшості програм WiFi, які я бачив, поріг RTS за замовчуванням встановлений у 2347 (з того, що я читав у різних місцях, цей параметр вважається "відключеним"), а поріг фрагментації встановлений у 2346. Моя конкретна марка маршрутизатора встановлюється в 2346 і 2346. У мене є кілька питань ...

1. Звідки походить значення 2346? Однак це здається дещо довільним, нотатки для Frag. Поріг вказує, що його потрібно перевищувати 256 і парне число.

2. Як РТС і Фраг. Порогові значення, пов'язані? Їх значення не можуть бути випадковими.

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 використовувати їх для передачі і не змушує клієнтів використовувати їх для передачі.

Цей змішаний сценарій б / г особливо неоптимальний. Ви можете переглянути деякі попередні дискусії з цієї теми, такі як:

Найповільніший бездротовий клієнт диктує якість підключення всіх інших?

Крім того, інший вбивця продуктивності виникає, коли точка А може приймати сигнал точки В, але B не може приймати сигнал A. Хтось ще на ServerFault вказав це на "ефект прихованого передавача". Детальніше про ці явища за посиланням нижче. Вони вказують, що:

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

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

Я не погоджуюся з тим, що "якщо у вас немає проблеми з прихованим вузлом, зміна порогу RTS не покращить продуктивність". Використання CTR / RTS завжди знижує шанси зіткнення даних. Оскільки кожне зіткнення даних спричиняє пошкодження даних і, таким чином, вимагає повторного надсилання даних, менша кількість зіткнень означає меншу кількість повторної передачі даних, а менша кількість повторної передачі даних може значною мірою покращити вашу роботу Wi-Fi; звичайно, лише якщо у вашій мережі спостерігається значна кількість зіткнень.

Щоб пояснити деталі: Вузол завжди повинен зачекати певний проміжок часу і відчути канал для можливих передач, перш ніж заявити про власний. Тільки якщо він не відчуває жодної передачі, він може запустити власну. Без RTS / CTS ця передача є безпосередньо передачею даних. Якщо зараз два вузли мають одне і те ж уявлення і розпочати передачу даних майже одночасно, то ці передачі зіткнуться. У результаті виходить, що жодна передача не робить її нікуди, оскільки всі отримані дані будуть пошкоджені для всіх інших вузлів та AP.

Якщо використовується 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 просто додає накладні витрати без практичного виграшу.

А тепер ви також знаєте, як поріг фрагментації може покращити продуктивність мережі. З одного боку, він обмежує розмір відправлених пакетів і, як пояснено вище, чим менший пакет в результаті зіткнення, тим швидше мережа відновиться від нього. А з іншого боку, якщо сталося зіткнення, потрібно повторно надіслати лише уражений ним фрагмент, а не весь пакет. Однак кожен надісланий фрагмент має власні накладні витрати, тому чим більше фрагментів, що надсилаються, тим більше накладних витрат, які додаватимуть і накладні, в основному витрачається на пропускну здатність, яка також могла бути використана для передачі даних.