Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(не баг) Деградация скорости в 2.4ГГц

Роутер: 3.9.16.RU.15112021 / Маршрутизатор / MT7620 2T2R 2.4GHz, MT7613 2T2R 5GHz, 100FDX (на старых версиях та же песня).

Клиенты: Debian 11, Intel 9642; Embedded Atheros; всякое телефоньё под Android 11.

Суть: пока нет интенсивного обмена трафиком, показывает в вебморде скорости подключения в пределах 130-325 Мбит/с в зависимости от устройства, как только нагружаешь трафиком, например видеопотоком 2-4Мбит/с, скорость тут же падает до 6-54 Мбит/с. Утилизация эфира стабильно устанавливается на 83-86%. RSSI в пределах -60 -75. Закачка заканчивается, скорость подключения тут же возвращается на высокие значения. Те же устройства но на 5ГГц не имеют проседания по скоростям подключения и соответственно поток стабильно льётся. К сожалению, не особо получается по уровню сигнала перейти полностью в 5ГГц. В радионастройках установлена только авторизация WPA2/3-PSK и мульти сеть в 2,4ГГц, остальное по умолчанию.

По логу с такими данными идет подключение одного и того же устройства:

Nov 25 23:45:43 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=1 to 5GHz AP 84:1b:77, PMF connect (WPA2PSK/AES)
Nov 26 00:23:19 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=1 to 2.4GHz AP 84:1b:77

Правда на стороне клиента сообщается о типе защиты WPA3-SAE.

 пока нет интенсивного обмена трафиком, показывает в вебморде скорости подключения в пределах 130-325 Мбит/с в зависимости от устройства, как только нагружаешь трафиком, например видеопотоком 2-4Мбит/с, скорость тут же падает до 6-54 Мбит/с. Утилизация эфира стабильно устанавливается на 83-86%. RSSI в пределах -60 -75. Закачка заканчивается, скорость подключения тут же возвращается на высокие значения.

Так работает rate alg, пока нет обмена данными выбирается стартовое значение рэйта исходя из таблиц RSSI<=>Rate. Как только начинается передача rate alg получает данные о TxPer и ориентируясь на него снижает скорость пока Per не будет в разумных пределах.

TxPer считается исходя из того подтвердил ли клиент доставку или нет (ACK механизм).

Проблема в том, что высокий RSSI абсолютно не гарантия того, что передача вообще возможна. Важен сигнал шум. Увы для 7620 мы такой инфы не получим, не умеет он NoiseFloorLevel отдавать. ;(

Но скорее всего у вас там в  эфире что-то фонит на смежном канале (в 2.4 увы и ах сейчас всё плохо) и имеете Client Side интерференцию, в итоге клиент не может декодировать то что посылает ему ТД.

Что можно сделать на стороне ТД?
1) методом перебора с тестом iperf попробовать найти таки канал где будет макс скорость достигаться
2) попробовать преключиться в 20МГц
3) последовательно принудительно поотключать плюшки 802.11 косвенно повышающие требования к SNR линка (TxBurst, Aggregation MSDU, Pkt Aggregate)

Правильное решение тут это взять второй девайс, ткнуть его в режим АП кабелем к основному, чем обеспечить человеческое покрытие в 5ГГц. 2.4ГГц нынче юзабелен, часто, только как приземлялка древних клиентов которые вообще 5ГГц не умеют. Эфир в 2.4 окончательно убит, и далеко не только WiFi.

Понял. Спасибо.

Не за что. Увы, как бы я не пытался подпилить адаптацию, но уже физика ограничивает возможности. Оптимизациях под 2.4 почти в тупике. Как минимум на чипах < 7615.

Любопытно стало как роутеру видится эфир, выбрал автовыбор канала и посмотрел чего намеряет.

Nov 28 21:25:25 kernel: Channel 1 : Dirty = 536, False CCA = 156, Busy Time = 17835, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 2 : Dirty = 542, False CCA = 237, Busy Time = 17929, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 3 : Dirty = 380, False CCA = 110, Busy Time = 11855, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 4 : Dirty = 466, False CCA = 120, Busy Time = 9915, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 5 : Dirty = 442, False CCA = 10, Busy Time = 8450, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 6 : Dirty = 320, False CCA = 137, Busy Time = 9398, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 7 : Dirty = 298, False CCA = 96, Busy Time = 7278, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 8 : Dirty = 298, False CCA = 70, Busy Time = 8447, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 9 : Dirty = 304, False CCA = 29, Busy Time = 5506, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 10 : Dirty = 410, False CCA = 27, Busy Time = 8197, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 11 : Dirty = 322, False CCA = 71, Busy Time = 9285, Skip Channel = FALSE
Nov 28 21:25:25 kernel: Channel 12 : Dirty = 264, False CCA = 83, Busy Time = 5069, Skip Channel = TRUE
Nov 28 21:25:25 kernel: Channel 13 : Dirty = 410, False CCA = 44, Busy Time = 7680, Skip Channel = TRUE
Nov 28 21:25:25 kernel: Channel 14 : Dirty = 212, False CCA = 53, Busy Time = 576, Skip Channel = TRUE
Nov 28 21:25:25 kernel: =====================================================
Nov 28 21:25:25 kernel: Rule 1 CCA value : Min Dirtiness (Include extension channel) ==> Select Channel 11 
Nov 28 21:25:25 kernel: Min Dirty = 620

И немного спустя:

Nov 28 21:37:14 kernel: Channel 1 : Dirty = 324, False CCA = 194, Busy Time = 16134, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 2 : Dirty = 280, False CCA = 81, Busy Time = 16466, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 3 : Dirty = 196, False CCA = 93, Busy Time = 8774, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 4 : Dirty = 184, False CCA = 175, Busy Time = 12770, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 5 : Dirty = 206, False CCA = 332, Busy Time = 13988, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 6 : Dirty = 144, False CCA = 132, Busy Time = 14645, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 7 : Dirty = 146, False CCA = 20, Busy Time = 6241, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 8 : Dirty = 112, False CCA = 233, Busy Time = 15159, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 9 : Dirty = 172, False CCA = 419, Busy Time = 24209, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 10 : Dirty = 256, False CCA = 162, Busy Time = 30523, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 11 : Dirty = 168, False CCA = 312, Busy Time = 34065, Skip Channel = FALSE
Nov 28 21:37:14 kernel: Channel 12 : Dirty = 152, False CCA = 16, Busy Time = 966, Skip Channel = TRUE
Nov 28 21:37:14 kernel: Channel 13 : Dirty = 288, False CCA = 36, Busy Time = 8058, Skip Channel = TRUE
Nov 28 21:37:14 kernel: Channel 14 : Dirty = 136, False CCA = 45, Busy Time = 261, Skip Channel = TRUE
Nov 28 21:37:14 kernel: =====================================================
Nov 28 21:37:14 kernel: Rule 1 CCA value : Min Dirtiness (Include extension channel) ==> Select Channel 3 
Nov 28 21:37:14 kernel: Min Dirty = 342

Как вижу, он суммирует значения загаженности на основной+расширенный каналах и на этом принимает решения о выборе канала. Штука прям очень кофейногадательная.  Почему-то отбрасываются высокие каналы. Из последнего замера Грязь 8+12=264, но выбирается почему-то 3+7=342. Или всё-таки оценка чистоты (Wlan+неWlan) и время тоже учитывается?

Сам эфир выглядит так:

20211128000001

P.S. Не по этому вопросу, просто попутно:

Nov 28 21:29:54 kernel: do_page_fault(): sending SIGSEGV to nginx for invalid read access from 00547608
Nov 28 21:29:54 kernel: epc = 00465938 in nginx[400000+a5000]
Nov 28 21:29:54 kernel: ra  = 00465938 in nginx[400000+a5000]

 

Почему в регионалках стоит 1-14, но в списке нет 14 канала?

  1. полный лог с pagefault приведите не вырывая из контекста что бы Sadler посмотрел когда появляется и повторил
  2. потому что 14й канал не доступен в 40МГц, и не помню, но помойму даже в N вообще да и врятли ваши девайсы будут с 14м работать. В любом случае он вам ничего не даст, как и автовыбор.
  3. не бывает выбора без выбора, алгоритм выбора сильно сложнее, но ещё раз говорю это всё откровенное бесполезно, выкинул бы из ПО вообще ибо больше вреда от всей этой автоматики, да вот верующие в умные выборы каналов в диапазоне где выбора нет и схема с защитным интервалом помещается ровно одна 1/11 по 20МГц, и без интервала 1/7/13  =)) Ну нет от него толку в современном эфире ещё и в широкой полосе в муравейниках. Только перебор с контролем iperf. Но завтра у соседей автовыбор сработает и опять будете перебирать. =)

Каналы эти 5МГц, весь диапазон 60МГц. 2 устройства работающие в 40МГц вы не засуните в 60МГц без пересечений. =) Вот и вся грязь. =)) Результат всегда такой, если пытаться впихивать невпихуемое типа 20МГц в 5МГц. =)))))

Есть же всё на форуме, не раз расписывал, даже со спектром https://wi-cat.ru/forums/forum/23/ поиск рулит.

В общем как уже было сказано уходите в 5ГГц.

P.S. Как выглядит эфир вы сканированием не увидите. Причём в 2.4 особенно. Это только краешек в виде 802.11. =)))

Хм, а вот с логом уже наверное не помогу. Почему то в нем оказалось вырезано всё от последней прошивки 25.11 до сегодняшнего дня. Причем сегодня лог стартанул по событию подключения клиента, т.е. перезагрузки не было. И то, что я копировал по автовыбору тоже исчезло. Еще в логах лежит nginx-error.log, но он пустой и дата создания именно после перепрошивки 25.11, хотя ошибка вебсервера была 28.11. Но как я помню, по логу (стоит info) ничего до ошибки не было криминального, обычные переподключения клиентов и всё, потом вывалилась ошибка и дальше опять тишина. А по моим действиям было переключения между вкладками "маршрутизатор" и "радионастройки основные", где либо канал менялся, либо запускалось сканирование эфира.

 

P.S. Создам новую тему.

P.P.S. Может тогда вообще убрать из регионалок 1-14 каналы, ограничится 1-13, если всё равно 14 выбрать не даете.

P.P.P.S. И непонятно, что за "График подключений беспроводных клиентов" который вечно пустой. Попытка создать меню расписания работы клиентов?

  1. Сислог имеет ограниченный размер ибо внезапно хранится в памяти, и ессно тратить её на хранение огромных логов расточительно
  2. Эта крутилка не вас в выборе ограничивает, вам вообще там крутить ничего не стоит. От неё зависит что устройство анонсирует клиентам.
  3. А выбрать клиентов в таблице выше параметры которых отображать

Можно как-то всё же не сваливать всё в кучу? Ну функционал/репорты и прочее. Есть же разделы разные для этого. Спасибо.

Обычно лог дописывается, ну никак не вырезается средняя часть? Шло, шло 25 число и опа, сразу 29 пошло.

Две соседние строчки в логе:

Nov 25 23:30:45 ntp: Starting NTPD.
Nov 29 03:27:23 udhcpd[3876]: sending OFFER to 192.168.222.26

ОК, закругляюсь.

Он и не вырезвэается. 25е поди дата сохранения рвфс куда и время пишетсч. В итоге 29го перезагрузились (например из-за) оом (судя по соседней теме) в итоге первые записи до синзронизпции времени, т.е. о. 25го

Кстати, можно иначе решить вашу проблему.

Пройтись по соседям и либо растащить ближайших 3их и вас в 20МГц 1/11 либо всех на один канал в 40.

Так хоть логика CSMA сможет доступ к среде передачи отруливать и интерференция упадет значительно, что позволит работать всем с более-менее приемлемыми скоростями.

Как минимум по тем кто с 70 и выше уровнями.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: