MikroTik RBSXTG-2HnD

[Saab95]

1. А тест максимально теоретических делать по UDP или TCP ?

2. А если в 40Mhz то должно быть 260Мбит ?

3. При 20mhz на 8-14 CCQ 99%/99%, перевожу в 40Mhz 8-14 CCQ 99%/88% если 8-13 то 95%/99%. Из за чего в 40Mhz падает CCQ?

 

p.s. Есть ли смысл использовать 40Mhz в PMP при зажатых канальных скоростях ?

 

Тесты только по UDP, вы же скорость тестируете.

 

Что должно быть проверяете на столе. В некоторых случаях, например при работе в нстриме, в одну сторону более определенной скорости не проходит, но можно запустить дуплексный тест с указанием максимальных скоростей, для проверки суммарной скорости. После проверок в любом случае нужно запускать дуплексный тест для проверки стабильности, например получили по тесту 100М, запускаете дуплексный тест 50М и смотрите, все ли проходит. Дуплексный тест не обязательно запускать симметричный, можно 70/30.

 

В 40мгц ширина канала больше, поэтому качество связи несколько хуже. Нужно понимать для чего используется режим 40мгц.

Например у вас канал не работает на максимальных канальных и 8-14 для него предел, ставите 15 уже скорость не увеличивается и CCQ падает. Если вы просто на 8-14 включите 40мгц, то, теоретически, удвоите скорость, но на 8-14, как сами заметили, в одну сторону связь хуже, это говорит о проблемах по этому направлению, если вы уменьшите максимальную канальную до 8-13, снова получите 100 процентное качество, естественно, скорость в этом режиме будет намного больше той, что получали в 20мгц. Поэтому если у вас на 8 получается одна скорость в 20мгц, то на 8 в 40 она будет в 2 раза выше, соответственно этим эффектом и пользуются.

 

Так же вариант работы такой - есть канал с перекосом по сигналам, например такими:

ch0 -60/-62

ch1 -77/-78

 

Вы можете работать:

1. В одноканальном режиме на 0-7 в полосе 20 и получите к примеру 50мбит.

2. В одноканальном режиме на 0-7 в полосе 40, получите например 100мбит.

3. В двухканальном режиме на 8-11 в полосе 20 получите те же 50мбит.

4 В двухканальном режиме на 8-11 в полосе 40 и получите 100мбит.

 

Естественно варианты равны по скорости, но 1 и 2 требуют большей энергетике, т.к. канальные скорости максимально высокие, варианты 3 и 4 работают на низких канальных, поэтому при наличии помех, этот вариант будет надежнее. Особенно если нет перекоса по каналам.

 

При этом важно всегда отключать галочки с режима А и убирать галочки с 0-7, если вы работает в МИМО и качество канала хорошее, если качество не совсем хорошее, то нужно всегда определять максимальную канальную скорость, на которой работает, и ее ставить, что бы оборудование не пыталось перепрыгнуть на более высокие скорости. Максимальная скорость определяется тестом.

 

Так же, для понимания, можете зажать максимальные скорости, на которых плохо работает, например на 15, клиент подключится, но при попытках передачи данных скорость будет низкая и могут быть обрывы, однако данные все равно передаются (если параметры радио позволяют). Соответственно если вы не указываете канальные скорости и ставите просто в авто, то оборудование может прыгать и на режимы А, и на режимы 0-7, и на 8-15, при этом реальная скорость оказывается не той, которую можно получить при грамотной настройке.

[divxl]

Спасибо за столь информативный ответ.

 

Задам еще несколько вопросов:

 

Тесты только по UDP, вы же скорость тестируете.

 

А что тестируется тестом TCP?

 

После проверок в любом случае нужно запускать дуплексный тест для проверки стабильности, например получили по тесту 100М, запускаете дуплексный тест 50М и смотрите, все ли проходит. Дуплексный тест не обязательно запускать симметричный, можно 70/30.

 

А что я должен увидеть в плане стабильности? т.е. если по тесту получил 100М, то в дупликсном должно проходить 70/30, а если не проходит, то что? Уменьшать канальную скорость?

 

При этом важно всегда отключать галочки с режима А

 

Это Вы про Date Rates? Если да, то отключаю все галочки.

 

Максимальная скорость определяется тестом.

 

Вот пример, определяю тестом, что при 8-12 максимальная скорость 120Mb CCQ 100% (теоретические 160), а при 8-13 140Mb CCQ 95-99% (иногда падает до 80%. Теоретические 216Mb), что выбрать?

 

 

Еще остался не понятный момент, к примеру есть база с 20 абонентами, подключаем нового и проводим тест. В момент теста сектор передает 40Mb трафика, не будет ли это влиять на определение "на какой канальной скорости работать" ?

 

 

Соответственно если вы не указываете канальные скорости и ставите просто в авто, то оборудование может прыгать и на режимы А, и на режимы 0-7, и на 8-15, при этом реальная скорость оказывается не той, которую можно получить при грамотной настройке.

 

Пока работаю в авто и не представляю, что будет при переходе на "зажатые каналы". Получается при самом плохом раскладe (например на базе с 21 абонами ветром согнуло мачту у одного), если установлены канальные скорости 8-13, то клиент уйдет в 8 и скорость в MIMO будет до 20Мбит, а остальные 20 абонетов как будут работать? В некий промежуток времени будет падать скорость до 20Мбит?

Edited October 20, 2015 by divxl

[Saab95]

А что тестируется тестом TCP?

 

Передача трафика по протоколу TCP. Этот тест показывает более прикладные данные, например если канал с потерями, или скорость не стабильная, он выдаст низкие результаты. Если все хорошо, то высокие. В обсуждаемом случае и 99 других случаях, проверять скорость нужно именно по UDP.

 

 

А что я должен увидеть в плане стабильности? т.е. если по тесту получил 100М, то в дупликсном должно проходить 70/30, а если не проходит, то что? Уменьшать канальную скорость?

 

Бывает что при тесте на прием и на передачу по очереди все хорошо, а при двунаправленном трафике в какую-то одну сторону наблюдаются проблемы. Поэтому и смотрят, получили в каждую сторону по 100мбит, значит дуплексом должно прокачать 50/50. Если при дуплексном тесте CCQ высокое, значит все ок.

Бывает и так, что от базы к клиенту скорость 100, а обратно 50 (например база помехи ловит и не может принимать на высоких канальных, а клиент помех не ловит и на приеме все хорошо), тогда дуплексный тест следует так же поделить по полученным результатам и установить 50/20, если по тесту что-то пойдет не так, то корректируете значения, например 40/20, 50/15, 60/10 и т.п.

 

Если не проходит то и не проходит, просто принимается как факт. Можно антенны покрутить. Частоту поменять и т.п.

 

Вот пример, определяю тестом, что при 8-12 максимальная скорость 120Mb CCQ 100% (теоретические 160), а при 8-13 140Mb CCQ 95-99% (иногда падает до 80%. Теоретические 216Mb), что выбрать?

 

Выбрать то, где прокачка лучше и стабильнее.

Суть тут вот в чем, для примера цифры с потолка, канальная скорость - прокачка:

 

8 - 20М

9 - 40М

10 - 80М

11 - 100М

12 - 120М

13 - 140М

14 - 160М

15 - 180М

 

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

 

Другой вариант:

 

8 - 20М

9 - 40М

10 - 80М

11 - 100М

12 - 120М

13 - 130М

14 - 120М

15 - 100М

 

Тут видно, что до 12 идет рост скорости, на 13 рост не значительный, тут уже и CCQ уменьшается, при дальнейшем увеличении канальной скорости, будет уменьшение пропускной способности и падает CCQ. Естественно это верно для зажатия только одной галочки, что бы оборудование не могло скинуть скорость при потерях. Попробуйте сделать такой тест и увидите что да как.

 

 

Еще остался не понятный момент, к примеру есть база с 20 абонентами, подключаем нового и проводим тест. В момент теста сектор передает 40Mb трафика, не будет ли это влиять на определение "на какой канальной скорости работать" ?

 

Тут не обязательно гонять трафик в больших объемах, достаточно дуплексного теста 5/5 и наблюдения за канальными скоростями и CCQ. Тестами проверяют работу и выбирают определенные канальные в основном на каналах точка-точка или многоточка с не большим количеством абонентов. Когда их много, тесты не объективный показатель качества работы.

 

Пока работаю в авто и не представляю, что будет при переходе на "зажатые каналы". Получается при самом плохом раскладe (например на базе с 21 абонами ветром согнуло мачту у одного), если установлены канальные скорости 8-13, то клиент уйдет в 8 и скорость в MIMO будет до 20Мбит, а остальные 20 абонетов как будут работать? В некий промежуток времени будет падать скорость до 20Мбит?

 

Если у вас авто и сдуло антенну, у абонента скорость и на 6М режима А может уйти, это хуже, чем на 8 в мимо. Если такой абонент будет просто висеть и не качать, другие абоненты не сильно пострадают, если же он будет качать, то время занятости этим абонентом канала повлияет на скорость у всех.

Тут просто, например хороший абонент за секунду передает 100 мегабит, плохой 10, складываем 100 и 10 получаем 110 и делим на 2, выходит работая оба они выкачают 55 мегабит. Это при равном делении эфира, на практике падение более значительное на wi-fi системах.

 

При работе БС можно попробовать установить тип буфера PCQ на беспроводной интерфейс, тогда база сможет гибко управлять передачей трафика в равной степени для всех абонентов, на приеме ничего сделать нельзя, т.к. что беспроводной адаптер принял, то и пойдет дальше. Однако такая тонкая настройка требует времени на тестирования и наблюдения, не во всех случаях дает положительный результат. Часто применяется для случаев, когда надо просто поделить всем скорость.

[divxl]

Передача трафика по протоколу TCP. Этот тест показывает более прикладные данные, например если канал с потерями, или скорость не стабильная, он выдаст низкие результаты. Если все хорошо, то высокие. В обсуждаемом случае и 99 других случаях, проверять скорость нужно именно по UDP.

 

Почему спросил, при тестировании внешнего канала (до микротика с внешним IP в другой сети) от устройств за NAT, UDP тест на прием не работает. Он как бы начинается идет шкала, но скорость не рисует/пишет. В чем может быть проблема?

 

Конфиг NAT:

add action=masquerade chain=srcnat src-address=192.168.18.0/24

 

 

Когда их много, тесты не объективный показатель качества работы.

 

 

А на что обращать внимание ? Полагаю на отсутствие "плохих" абонентов в общей массе и перекосов по поляризациям? Ну и плюс при подключении новых как Вы писали:

Тут не обязательно гонять трафик в больших объемах, достаточно дуплексного теста 5/5 и наблюдения за канальными скоростями и CCQ.

 

 

При работе БС можно попробовать установить тип буфера PCQ на беспроводной интерфейс, тогда база сможет гибко управлять передачей трафика в равной степени для всех абонентов,

 

А при буфере по умолчанию (sfq), как происходит передача данных (не равномерно)? Или при том который советовали в другой теме PFIFO = 1000 ?

[DRiVen]

divxl, здесь переводная статья.

[ЯGUAR]

Паралельный вопрос

 

Можно ли собрать что то типа омнитика но в 2.4 ггц

[Saab95]

Почему спросил, при тестировании внешнего канала (до микротика с внешним IP в другой сети) от устройств за NAT, UDP тест на прием не работает. Он как бы начинается идет шкала, но скорость не рисует/пишет. В чем может быть проблема?

 

Тесты нужно делать внутри сети. Как вы пишите это симптом того, что связь есть только в одну сторону, то есть на передачу трафик идет через сеть интернет до адресата, а на приеме у вас нат. Поднимите L2TP туннель через интернет для связи и запускайте тест уже по внутренним адресам.

 

 

А на что обращать внимание ? Полагаю на отсутствие "плохих" абонентов в общей массе и перекосов по поляризациям? Ну и плюс при подключении новых как Вы писали:

 

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

 

Как я уже писал - если есть плохие абоненты, нужно поставить для них отдельную базу.

 

А при буфере по умолчанию (sfq), как происходит передача данных (не равномерно)? Или при том который советовали в другой теме PFIFO = 1000 ?

 

При sfq база пытается позволить всем предоставить равные условия для передачи данных, для 802.11 это оптимально, при использовании поллинговых протоколов нет.

PFIFO оптимально использовать на линках точка-точка, когда только один клиент и весь буфер достается ему. На базах его тоже можно использовать, но эффективность снижается.

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

 

Паралельный вопрос

 

Можно ли собрать что то типа омнитика но в 2.4 ггц

 

Можно, BaseBox 2, накручиваете 2 маленькие уличные антенны микротиковские или от RF Elements, или от пикостанции убнт. Проблема в том, что горизонтальных всенаправленных антенн нет (или есть, но цена не понравится =)

Поэтому и нет решений, аналогичных омнитику. Тут самое выгодное 3-4 секторную БС поставить с МИМО антеннами.

[divxl]

Тесты нужно делать внутри сети. Как вы пишите это симптом того, что связь есть только в одну сторону, то есть на передачу трафик идет через сеть интернет до адресата, а на приеме у вас нат. Поднимите L2TP туннель через интернет для связи и запускайте тест уже по внутренним адресам.

 

Действительно, поднят PPTP тоннель и по адресу сервера PPTP тест проходит. Не понятно почему тогда TCP тест проходит по внешнему IP а UDP нет ?

[Saab95]

Действительно, поднят PPTP тоннель и по адресу сервера PPTP тест проходит. Не понятно почему тогда TCP тест проходит по внешнему IP а UDP нет ?

 

Потому что TCP создает TCP соединение, соответственно может через НАТ работать.

[divxl]

Потому что TCP создает TCP соединение, соответственно может через НАТ работать.

 

А как же тогда скайп да торренты работают ?

[Saab95]

А как же тогда скайп да торренты работают ?

 

Они отправляют запрос и получают ответ. Тест скорости запросов никаких не отправляет.

[divxl]

В режиме PMP канальные скорости зажимаем только на базе?

 

На клиентах все в авто, верно?

[Saab95]

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

[TTvs]

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

 

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

Edited October 30, 2015 by TTvs

[Saab95]

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

 

Да, на базе. Однако в сложных случаях, при работе в нстриме, можно зажимать верхние канальные скорости на клиентах, что бы они не пытались поставить высокие и не падал CCQ. Однако так делать можно только в исключительных случаях, т.к. если абонент антенну выключит, а вы на базе поменяете настройки, он потом не подключиться.

 

Пример простой, например у вас есть 10 хороших клиентов на базе, но надо подсадить плохого, что бы он не портил всем работу, на этом клиенте зажимаете сильно канальные скорости, что бы CCQ было 100.

[TTvs]

например у вас есть 10 хороших клиентов на базе, но надо подсадить плохого, что бы он не портил всем работу, на этом клиенте зажимаете сильно канальные скорости, что бы CCQ было 100.

В этом случае база будет работать на хороших клиентах, например на MCS15, а на плохом клиенте только на MCS8? Или она перейдёт на MCS8 для всех? Вы же говорили, что один плохой клиент портит работу всем остальным..

[Saab95]

В этом случае база будет работать на хороших клиентах, например на MCS15, а на плохом клиенте только на MCS8? Или она перейдёт на MCS8 для всех? Вы же говорили, что один плохой клиент портит работу всем остальным..

 

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

 

Проблема плохого клиента имеет 2 разновидности:

1. Потерь нет, но низкая скорость. Тут просто общее падение скорости при передачи данных к и от абонента.

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

[slv700]

например у вас есть 10 хороших клиентов на базе, но надо подсадить плохого, что бы он не портил всем работу, на этом клиенте зажимаете сильно канальные скорости, что бы CCQ было 100.

В этом случае база будет работать на хороших клиентах, например на MCS15, а на плохом клиенте только на MCS8? Или она перейдёт на MCS8 для всех? Вы же говорили, что один плохой клиент портит работу всем остальным..

Один плохой клиент может испортить работу всей базы и всех клиентов. Основные причины две ( но есть еще и другие):

1) известная проблема "скрытого узла" ( hidden node), когда есть клиенты, которые не видят (не слышат) друг друга. Нарушает работу шедулера ( раздачи) базы, когда один клиент работает ,а остальные ( главным образом "плохие") отдыхают. Проявляется при увеличении аплода трафика хотя бы с одного близкого ( хорошего) клиента на стандартном CSMA протоколе и отчасти на поллинговом протоколе ( больше на Airmax,меньше на Nstreme/Nv2). На TDMA Камбиум ePMP данной проблемы нет.

2) "плохой" клиент , это когда выполняется хотя бы одно из трех условий: низкие сигналы RSSI ( в том числе разброс сигналов по поляризациям и значительные относительные различия в UL RSSI между клиентами), низкий data rate, большая дальность клиента ( точнее значительные различия в дальностях до клиентов). Нарушает работу шедулера, когда он пытается хорошо( нормально ) обслужить плохого клиента за счет всех остальных.

Проблема есть у всех поллинговых протоколов и CSMA. На TDMA Камбиум ePMP этой проблемы особо нет, хотя можно играться с приоритезацией обслуживания клиентов с низкими модуляциями, что может повысить эффективность обслуживания всех клиентов базы.

Основной способ борьбы с данной проблемой на убнт и микротике- 1) не работать в CSMA 2) выравнивание условий подключения клиентов ( сигналов, модуляций, дальностей и видимости базы со стороны клиентов и друг друга)- то есть чем в более равных условиях находятся ВСЕ клиенты ( то есть нет очень плохих и очень хороших клиентов), тем сбалансированней работает шедулер при обслуживании клиентов.

[TTvs]

Спасибо. Речь шла о Микротике.

[divxl]

Основной способ борьбы с данной проблемой на убнт и микротике- 1) не работать в CSMA

 

В NV2 нет CSMA по умолчанию ?

[TTvs]

В NV2 нет CSMA по умолчанию ?

Нет. Вопрос был про канальные скорости. slv700 начал затаскивать нас в дебри работы протоколов, чтобы показать, что его Камибиум работает не в режиме Wi-Fi.

[slv700]

Спасибо. Речь шла о Микротике.

Я сравниваю Микротик с убнт и Камбиум, чтобы было понятна принципиальная системная проблема именно в протоколе множественного доступа, а не в том, что микротик плохо настроили, кривые руки, глючит софт и т.п. При сравнении CSMA , поллинга с TDMA я говорю о реализации TDMA именно на Камбиум ePMP. Откройте мои посты 6 летней давности. Я говорил то же самое, но в сравнении с TDMA в реализации fixed wimax. Почему TDMA на ePMP и wimax? Потому что убнт имеет наглость утверждать что у него видите ли тоже TDMA, да еще с синхронизацией. Ни то, ни другое,мягко сказать, неправда. И Микротик также хотел ранее выдать Nv2 за TDMA, но потом все же согласился , что это типа "групповой поллинг". А вот у fixed wimax, ePMP,PMP450 и др., например Radwin, Redline и др. в малтипойнт- полноценный TDMA, который не имеет рассмотренных выше проблем. И пока Микротик ( а также это касается убнт) не сделают правильный протокол у них эти проблемы, которые носят системный характер, останутся. И они не решаются "тонкими" и правильными настройками Микротика, переходом с чипа N на чип АС, исправлением кривых рук инсталляторов и прочее.

[TTvs]

Вам за это платят что-ли? За то, чтобы в каждой теме вы обязательно упоминали свой Камбиум..

[slv700]

За то, чтобы люди, когда ставят то или иное оборудование, понимали, что получат в итоге. И задавали подобные вопросы до того, а не после.

[TTvs]

В этом случае база будет работать на хороших клиентах, например на MCS15, а на плохом клиенте только на MCS8? Или она перейдёт на MCS8 для всех? Вы же говорили, что один плохой клиент портит работу всем остальным..

 

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

 

Проблема плохого клиента имеет 2 разновидности:

1. Потерь нет, но низкая скорость. Тут просто общее падение скорости при передачи данных к и от абонента.

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

 

Ограничил плохому клиенту модуляцию до MCS8. База работает на MCS13. На вкладке Registration получилось вот что (см.рис.). Красным обведён плохой клиент.

Что не так?