Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Обычный 802.11an лучше, чем NV2!

    Обычный 802.11an лучше, чем NV2!

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Обычный 802.11an лучше, чем NV2!, RouterOS
     
    WirelessRudy
    Guest
    #1
    0
    29.03.2018 15:18:00
    1 AP rb911G-5HpnD на всенаправленной антэнне 12dBi. 27 клиентов. В основном SXT-L, один SXT-Lac, один SXT-sq5ac, rb911, несколько 711 и даже три 411. Точка доступа в режиме моста, CPE маршрутизируют с PPPoE на wlan1. Управляющая сеть через DHCP-сервер на RouterBOARD 750G r3 за AP с vlan2, интерфейс vlan2 на CPE’s wlan1 с DHCP-клиентом. Тесты проводились с помощью Mikrotik bandwidth test с CPE, один TCP-подключение, загрузка. Полоса 40 МГц, AP работает на ROS v6.42rc52, прошивка обновлена до 6.42rc52:

    adaptive-noise-immunity=ap-and-client-mode  
    band=5ghz-onlyn  
    basic-rates-a/g=""  
    channel-width=20/40mhz-Ce  
    disconnect-timeout=3s  
    distance=dynamic  
    frame-lifetime=0  
    guard-interval=long  
    ht-basic-mcs=mcs-7,mcs-8,mcs-9  
    ht-supported-mcs=mcs-7,mcs-8,mcs-9,mcs-12,mcs-13,mcs-14,mcs-15  
    hw-fragmentation-threshold=disabled  
    hw-protection-mode=none  
    hw-protection-threshold=0  
    hw-retries=3  
    interworking-profile=disabled  
    keepalive-frames=enabled  
    l2mtu=1600  
    mode=ap-bridge  
    nv2-cell-radius=10  
    nv2-downlink-ratio=75  
    nv2-mode=dynamic-downlink  
    nv2-noise-floor-offset=default  
    nv2-qos=default  
    nv2-queue-count=2  
    nv2-security=enabled  
    on-fail-retry-time=100ms  
    preamble-mode=long  
    rate-selection=advanced  
    rate-set=configured  
    rx-chains=0,1  
    security-profile=AP-E  
    supported-rates-a/g=12Mbps  
    tdma-period-size=3  
    tx-chains=0,1  
    wireless-protocol=nv2  
    wmm-support=enabled  

    Неактуальные параметры опущены. AP можно переключать между wireless-protocol=nv2 и 802.11. Все CPE настроены в соответствии и работают на v6.41.3 с прошивкой 6.41.3. Только SXT-sq5ac тоже на 6.42rc52 с последней прошивкой (6.41.3 пока не поддерживает PPPoE на устройствах ‘arm’):

    adaptive-noise-immunity=client-mode  
    band=5ghz-onlyn  
    basic-rates-a/g=6Mbps  
    bridge-mode=enabled  
    channel-width=20/40mhz-Ce  
    compression=no  
    default-authentication=no  
    disconnect-timeout=3s  
    distance=dynamic  
    frame-lifetime=0  
    frequency-offset=0  
    guard-interval=long  
    hw-fragmentation-threshold=disabled  
    hw-protection-mode=none  
    hw-protection-threshold=0  
    hw-retries=3  
    interworking-profile=disabled  
    keepalive-frames=enabled  
    l2mtu=1600  
    mode=station  
    mtu=1500  
    multicast-buffering=enabled  
    multicast-helper=default  
    nv2-security=enabled  
    on-fail-retry-time=100ms  
    preamble-mode=long  
    security-profile=AP-E  
    tx-chains=0,1  
    wireless-protocol=any  
    wmm-support=enabled  

    Большинство остальных настроек наследуются от AP. RTS/CTS всегда включены в 802.11 режиме. Сеть работает в зоне, где практически на всех частотах есть другие Wi-Fi точки доступа, поэтому присутствуют помехи, но выбран максимально свободный канал. В рабочей сети при небольшой нагрузке я подключаю 4 клиента, с каждого CPE открываю один TCP-поток на загрузку с rb750gr. В сети нет очередей и приоритизации, поток идет от rb750gr по гигабитному кабелю через Netonix свитч к AP, а затем по воздуху к клиентам. Все клиенты подключаются примерно с уровнем сигнала от –38 до –55 dBm, худший – –57. Все тестовые клиенты показывают уровень сигнала на низких 50-х или лучше.

    Тест 1. 802.11n: При старте одного клиента скорость скачивания 80–почти 100 Мбит/с. При подключении второго первый теряет в скорости, оба держатся в районе 30–40 Мбит/с. Добавляем третьего и четвертого — у каждого скорость падает, но все колеблются в пределах 20–30 Мбит/с. За это время AP показывает общую пропускную способность в среднем до 115 Мбит/с с пиками до 130. Тест длился 2 минуты.

    Тест 2. NV2, переменный downlink 75%: Один клиент стартует со скоростью 40–50 Мбит/с, пикирует до 70 максимум. С добавлением клиентов скорость у всех падает, и в итоге все четыре ограничиваются 10–20 Мбит/с. При этом AP показывает среднюю пропускную способность около 70 Мбит/с с пиками почти 115, но в целом работа гораздо менее стабильна, чем в тесте 1.

    Тест 3. NV2, фиксированный downlink 75%: Почти так же, как в тесте 2, но есть ещё 5–10% потерь по общей пропускной способности.

    Вывод: 802.11n превосходит NV2 даже в сети с множеством CPE и сильными помехами. Честно говоря, перед заменой в трёх других сетях, которые сейчас используют Mimosa, мы сначала попробовали SXT ac в Mimosa ‘interop’ режиме, который на самом деле — обычный 802.11 с тонкой настройкой RTS/CTS. Мы были просто поражены приростом скорости у клиентов. Частично я приписываю это более мощным Mimosa AP вместе с более мощными SXT-ac, но после чтения тестов некоторых ребят на просторах интернета у меня уже сложилось впечатление, что 802.11 с RTS/CTS не так уж и плох, как пытаются нас убедить разные производители (они же всеми силами втягивают нас в свои проприетарные TDMA-протоколы, ведь если это удастся, клиенты будут меньше уходить к конкурентам)...

    Мой следующий проект — заменить все ‘n’ устройства в этой «тестовой» сети на ‘ac’ режим CPE, на что уйдет около месяца. А пока Mikrotik должен постараться ещё сильнее улучшить NV2! Когда вся моя сеть станет ‘ac’, я надеюсь выйти на скорости, близкие к тем, что сейчас дает Mimosa — 100, 150 или даже 200 Мбит/с на клиенте! Если это удастся, я вернусь к 100% поддержке Mikrotik. Потому что сеть P2MP ‘ac’ на 30 клиентов у Mikrotik всё ещё стоит гораздо дешевле, чем решения eCambium и Mimosa. И мы до сих пор дешевле, чем ubnt…
     
     
     
    enlace101
    Guest
    #2
    0
    27.11.2024 06:39:00
    В AP.. RTS/CTS CTS самому себе?
     
     
     
    bpwl
    Guest
    #3
    0
    27.11.2024 19:24:00
    802.11 CSMA/CA или NV2/TDMA — это как круговое движение и светофоры в автомобильном трафике. Что из них даёт лучший пропускной поток? Зависит от распределения и интенсивности трафика. Со светофорами (не учитывая действительно умные реализации) всегда есть вероятность фиксированного времени ожидания, в то время как на круговом движении такого нет. При очень плотном трафике со всех сторон ты почти не можешь заехать на круг, образуются большие пробки, и пропускная способность падает. То же самое было с Ethernet CSMA/CD против Token Ring — в 80–90-х шли жаркие споры с поклонниками IBM. Аналогично и с двумя беспроводными реализациями. 802.11 передаёт данные, когда только может. Хороший общий пропускной поток сильно зависит от больших передаваемых блоков (агрегаций), так как промежутки между передачами фиксированы и просто "съедают" эфирное время. NV2 использует централизованно управляемые фиксированные временные слоты для передачи. Промежутки между передачами меньше, поэтому возможна передача меньших блоков без значительных потерь пропускной способности. Что лучше? Ну, зависит от ситуации. 802.11 с большими A-MSDU и особенно большими A-MPDU эффективно использует эфирное время. Насколько я знаю, у NV2 нет таких механизмов, как A-MSDU и A-MPDU. Известно, что низкая производительность WLAN-драйвера объясняется маленькими размерами A-MSDU (MPDU) и A-MPDU. Эти значения размера видны в beacon. https://dot11ap.wordpress.com/a-mpdu-vs-a-msdu/ https://inet.omnetpp.org/docs/showcases/wireless/aggregation/doc/index.html
     
     
     
    holvoetn
    Guest
    #4
    0
    27.11.2024 20:12:00
    Ты же понимаешь, что это был ответ на тему, которой уже 6 лет?
     
     
     
    bpwl
    Guest
    #5
    0
    27.11.2024 22:26:00
    Позже да, просто ответил, исходя из пункта #9, поэтому это появилось в моём списке «активных тем», и я настраивал соединение (MT<->GL.inet). Первую дату увидел только потом. Проблема всё ещё остро стоит. Много проблем с OpenWRT (GL.inet, Cudy), даже на самых новых версиях вроде 23.03... появляются ошибки "lmac[0] Error, msdu index reach maximum limit, 31" при использовании MT uplink. На форуме OpenWRT советуют уменьшить параметр AMSDU limit в MT AP. Это же шутка, да? (Это значение 8192 из Winbox в ROS не используется, насколько я понял по MT beacons).
     
     
     
    enlace101
    Guest
    #6
    0
    28.11.2024 18:09:00
    Я очень благодарен за ваш ответ, он всегда такой подробный. Прошу прощения, что поднял старую тему. Мне срочно нужна была помощь, и это была первая ветка, которую я нашёл. У меня возникли проблемы с сетью NV2, и я в итоге переключил всё на 802.11, включил RTS/CTS на клиентах и установил порог аппаратной защиты на 512. На точке доступа оставил эти настройки на «none». Сейчас у клиента стабильный игровой пинг 32 мс вместо прошлых 80 мс. Теперь собираюсь заняться оптимизацией параметров AMSDU и AMPDU, чтобы ещё лучше настроить сеть. Ещё раз спасибо за вашу помощь!
     
     
     
    marekm
    Guest
    #7
    0
    28.11.2024 21:12:00
    Добро пожаловать обратно. RTS/CTS на точке доступа был отключён, но это не должно сильно влиять, так как все станции слышат точку доступа, просто станции часто не слышат друг друга (скрытые узлы), вот почему им и нужен RTS/CTS — по крайней мере, так я это понимаю. Не совсем понимаю, в каких случаях «CTS to self» на точке доступа может помочь.

    Заодно NV2, похоже, улучшился, хотя Cambium ePMP1000 на 6 ГГц работает лучше. Жаль, что MikroTik, судя по всему, прекратил разработку продуктов на 60 ГГц. Если бы существовала такая штука, как nRAY XL с поддержкой всех 6 каналов (на больший радиус действия), 31 станцией на точку доступа и резервным 5 ГГц — я бы не пришлось использовать ещё одну проприетарную супердорогую систему с привязкой к вендору (UBNT Wave), которая всё равно плохо справляется с некоторыми вещами (не может подключаться к существующей 5 ГГц точке доступа для резервного канала, чтобы хоть немного разгрузить и так забитый спектр, нет MAC ACL, чтобы заставить станции подключаться к нужному сектору, нет RSTP).
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры