[STALSKYU]

В одном из последних релиз-кандидатов RouterOS (начиная с версии 6.42rc46), разработчики сообщили о том, что им удалось провести оптимизации и улучшения, которые потенциально должны привести к существенному повышению пропускной способности точки доступа PtMP.

https://forum.mikrotik.com/viewtopic.php?f=21&t=132181

 

Также буду испытывать nv2-downlink-ratio и fixed-downlink

Начинаю тест на загруженной БС Netmetal5 32 абона.

Кто со мной? Го скрины настроек nv2 и графики....
 

 

[x-rayd]

У нас прирост на 30 клиентов с 30 Мбит до 50 Мбит.

[STALSKYU]

14 часов назад, x-rayd сказал:

У нас прирост на 30 клиентов с 30 Мбит до 50 Мбит.

Каковы твои настройки nv2?
У меня за сутки во че вышло

[x-rayd]

Only N, 20 Mhz, TDMA auto, dynamic downlink and 80% downlik ratio. MCS0-MCS7

[modnyman]

Омнитик, 30 радиоклиентов. Прошивка обновлена 24 числа. Видно что процент дропов на интерфейсе упал.

 

Более детально воскресенье:

раньше на такой нагрузке было до 2 процентов дропов.

 

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=client-mode ampdu-priorities=0,1,2,3,6,7 area=******** band=5ghz-a/n \
channel-width=20/40mhz-Ce default-authentication=no default-forwarding=no disabled=no frequency=5680 frequency-mode=superchannel \
guard-interval=long hw-retries=3 keepalive-frames=disabled mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-preshared-key=******** \
nv2-qos=frame-priority nv2-queue-count=8 nv2-security=enabled radio-name=******** scan-list=5100-5850 ssid=********  tdma-period-size=auto \
wireless-protocol=nv2

Изменено 27 марта, 2018 пользователем modnyman

[x-rayd]

@modnyman почему у Вас стоит adaptive-noise-immunity=client-mode?

Разве не должно стоять ap and client mode?

Поясните пожалуйста...

[modnyman]

@x-rayd Разъясните мне значения обоих параметров данной опции, возможно я изменю на ваш вариант)

[x-rayd]

этот параметр позволяет чипу, отфильтровывать шумы, ну как пример отражённый сигнал самой точки доступа от соседнего здания. Установите значение равное “ap and client mode”

[modnyman]

@x-rayd в чем различие между ап энд клиент и просто клиент?

[x-rayd]

client это если использовать точка точка

[Timax]

18 часов назад, modnyman сказал:

Омнитик, 30 радиоклиентов. Прошивка обновлена 24 числа. Видно что процент дропов на интерфейсе упал.

 

Более детально воскресенье:

раньше на такой нагрузке было до 2 процентов дропов.

 

/interface wireless
set [ find default-name=wlan1 ] adaptive-noise-immunity=client-mode ampdu-priorities=0,1,2,3,6,7 area=******** band=5ghz-a/n \
channel-width=20/40mhz-Ce default-authentication=no default-forwarding=no disabled=no frequency=5680 frequency-mode=superchannel \
guard-interval=long hw-retries=3 keepalive-frames=disabled mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-preshared-key=******** \
nv2-qos=frame-priority nv2-queue-count=8 nv2-security=enabled radio-name=******** scan-list=5100-5850 ssid=********  tdma-period-size=auto \
wireless-protocol=nv2

 

Скажите пожалуйста, а каким образом снимаете и считаете дропы? Интересно было бы посмотреть и реализовать такое.

[modnyman]

2 часа назад, x-rayd сказал:

client это если использовать точка точка

А можно всётаки выдержку из документации с внятным описанием различий?

[modnyman]

@Timax Дело не хитрое

Так как трафик везде у меня выходит даже с wlan c тегами, маркирую юникаст трафик вот так:

/interface bridge filter
add action=mark-packet chain=forward mac-protocol=vlan new-packet-mark=unicast out-interface=wlan1 packet-type=other-host vlan-encap=ip

ВАЖНО: метод маркировки может отличаться, если точка является ещё и маршрутизатором - лучше брать трафик уже меченый под шейпер, если не шейпится тут - просто маркируйте в манглах весь айпи трафик.

 

Дальше делаю дерево с родителем wlan интерфейсом:

/queue tree
add name=wlan1-tree parent=wlan1
/queue type
add kind=pcq name=wireless-downlink pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-limit=10KiB pcq-src-address6-mask=64 pcq-total-limit=250KiB
add kind=pfifo name=pfifo-downlink pfifo-limit=10
/queue tree
add name=unicast packet-mark=unicast parent=wlan1-tree queue=wireless-downlink
add name=non-unicast packet-mark=no-mark parent=wlan1-tree queue=pfifo-downlink

Весь не маркированный трафик - не юникаст. Арпы там всякие, мультикасты... Нече ему делать в очереди с писикью классификатором.
 

К вопросу почему такая короткая очередь:

Хотелось бы узнать вообще мнение людей знакомых с теорией очередей, или просто знающих... Какую лучше длину очереди делать?

Я брал общий размер из расчета на примерно 10 милисекунд при полной канальной утилизации, потом немного снизил и округлил. Длина на один поток взята минимальной, так как вообще не вижу смысла в этом месте шедулить трафик. Ведь за этой очередью следует очередь драйвера из которой осуществляется доступ к среде, агрегация кадров, смена порядка пакетов по 802.1p... Соответственно всё что задержалось в моем дереве - это перегрузка интерфейса, причем уже случившаяся. И тут возникает ещё аргумент не городить длинную очередь. Пакеты пойманные в дроп мы сможем отмониторить, и явно понять уровень перегрузки и построить график.

 

Ну а дальше дело мониторинга. Всё что нам нужно есть в мибах кроме процента отброшенных пакетов. Но у нас есть oid-ы для общего числа пакетов и для числа дропов. По снятым значениям в заббиксе создаем ещё одно вычисляемое, где второе делим на первое и умножаем на 100.

 

Ну и рисуем графики:

Левый, левая шкала, зеленый график - дельта нагрузки в мегабитах.

Левый, правая шкала, красный график - кол-во абонентов онлайн.

Правый, левай шкала, желты график - дельта нагрузки в пакетах.

Правый, плавая шкала, красный график - процент дропов - что есть в любом случае перегрузка. На слабо нагруженных базах дропов к слову нет вообще.

 

Если увеличить длину очереди - не сказал бы что это особо увеличит скорость (хотя отчасти увеличит). Но пропадет информативность и время для "маневра", чтоб отреагировать на данную проблему.

 

Да и вообще, я к этому решению довольно долго приходил, но пришлось прийти. Потому что бесит в микротике что невозможно понять когда иссякает емкость, не понять есть ли запас. Не понять когда абонент жалуется на скорость - не на базовой станции ли это? Срань полнейшая, почему из коробки это нельзя было сделать?

 

Очень жажду любой критики и советов.

Изменено 28 марта, 2018 пользователем modnyman

[Saab95]

Размер буфера надо ставить очень и очень большим, тогда не будет дропов абонентских данных, что разгрузит входящий канал интернета. Ведь если есть дропы, абоненты запрашивают данные повторно.

Так же и в беспроводном адаптере надо поменять буфер на PFIFO или так же на PCQ, что сможет позволить абонентам более равномерно распределять между собой емкость канала.

[modnyman]

"очень и очень большим" - можно в более конкретных значениях для pcq? И всётаки, какой в этом смысл если есть буфер драйвера? Да и какбы не имеет смысла накапливать пакеты в том числе слабых клиентов, так как весь их шедуленный трафик сожрет кучу эфирного времени и усугубит перегрузку, тогда как дроп - заставит поумерить аппетиты. И кстати всегда мучал вопрос - каков размер буфера драйвера? Не могу инфу нигде найти внятную.

 

Да и кстати, суммарный то размер очереди не такой уж малый, 250 килобайт. А потоки в свою очередь не накапливают много пакетов.

Изменено 29 марта, 2018 пользователем modnyman

[Timax]

В 27.03.2018 в 14:31, STALSKYU сказал:

Каковы твои настройки nv2?
У меня за сутки во че вышло

Клиентов тоже шьете? Или можно только БС?

[Saab95]

3 часа назад, modnyman сказал:

"очень и очень большим" - можно в более конкретных значениях для pcq?

5M размер буфера. Нет ничего страшного в задержках у абонентов в 200-500мс, все приложения сами понимают, что канал загружен и надо убавить скорость.

Если в радио вместо SFQ поставить PCQ, то общая скорость до абонентов увеличится, а вот на прием таким образом регулировать скорость не выйдет.

[modnyman]

Как тогда выявлять перегрузку интерфейса? И не только перегрузку, а степень плачевности ситуации?

 

"а вот на прием таким образом регулировать скорость не выйдет" ну, на этот случай fixed downlink теперь есть

[uraso]

Решил на одной из баз попробовать  новшество микротик. Залил  6.42rc52  в  RB912UAG-2HPnD с 25 клиентами.  Хотя еще релиз-кандидатов  не заливал без тестов ....  Была до этого прошивка  6.37.1 ... Обновление прошло без проблем. Сменился мак адрес. После перезагрузки опять вернулся на старый. Посмотрим вечером  как это новшество работает на 2.4G.

[airos23]

Обновился на 6.42rc52, на RB912UAG-2HPnD. Очень не понравился пинг до абонентов, то 10 мс то 150 то 13. В общем сильно вырос джиттер. Надеюсь в следующей версии прошивки пофиксят эту проблему.

P.S прошивал другую базу SXT 2, на ней аналогичная проблема с пингом. Стоит dynamic downlink , ratio 80%

[vasily]

Вчера тоже обновил базу на 6.42rc52, на mANTBox_19s. Пинг до абонентов, то 10 мс то 150 то 13. В общем сильно вырос джиттер. Надеюсь в следующей версии прошивки пофиксят эту проблему. но пропускная способность увеличилась. ранее на базе больше 35Мб не было. теперь одновременно запустив на пяти клиентах Бендвич тест скорость поднялась до 74Мб.тарифы у клиентов 7/1.

Изменено 5 апреля, 2018 пользователем vasily

[yKpon]

при обновлении наблюдается жалобы со стороны абонентов, "ничего кроме яндекса не открывается", откатываю обратно, всё ок

 

ни у кого подобного нет?

[Saab95]

На предмет настроек MTU посмотрите на БС.

[Yaten]

Косяк в мту

[npokypop]

Есть еще у кого результаты на RB912UAG-2HPnD ?