Alver

407025 просит ребут, сделайте это. В таблице Scan List. xls видно, что на рабочей частоте 5590 MHz Cambium работает туча устройств UBNT и RB c cигналом не меньше чем на базе Камбиум. Какой задан уровень Slave Module Target Receive Level в Radio-Configuration? Сделайте нормальный скрин СА, дайте время на отрисовку, чтобы видна была нижняя часть скрина с информацией о частотных каналах , на которых работают соседские РЭС. Замена (407013) на Force 180 помогла?

35-40 Mbps на сектор, это полка UBNT в малтипойнт на 30-40 клиентах. У Камбиум в ТРИ раза больше. И это не теоретически ( можно посчитать по калькулятору емкости ) , а на практике эксплуатации с 2013 года. Это справедливо и для родных CPE и для Elevate CPE. Примеры-скрины выкладывались много раз, в том числе скрины работы сектора Рокет с клиентами до того апгрейда и после апгрейда Eevate. Получен рост емкости в три раза и по max количеству клиентов и по емкости сектора по пропускной способности. Это все известно всем. Разбирайтесь откуда у вас появилась полка 45 Mbps в 20 Мгц . Нужна помощь, обращайтесь в суппорт.

Эти тесты неадекватные. В чем там фокус дано объяснение здесь .

Также рассмотрим в чем есть фокус с TCP тестом RB4011. Есть приложение -генератор тестов Bandwidth Test Mikrotik , выполняемое на нескольких ядрах -процессорах CPU устройства RouterBoard. Это проводится путем выделения супервизором задач операционной системы ROS ( Linux) каждому процессору-ядру кванта времени и последовательно по очереди выполняет это приложение на разных ядрах. То есть в каждый момент времени приложение работает только на одном ядре . Понятно, что такое исполнение программы последовательно на нескольких ядрах не ускоряет исполнение программы. Время исполнения ОДНОГО приложения на нескольких ядрах остается точно таким же как и на одном ядре . Однако ускорение есть для суммарного времени одновременной работы НЕСКОЛЬКИХ РАЗНЫХ приложений , за счет того, что исполнение программ распределено по по нескольким ядрам. На прошивке RoS ( вышла полгода назад) , где впервые при работе Bandwidth Test Mikrotik были задействованы несколько ядер , тест как и ранее на одном ядре, не мог генерировать больше чем TCP 200-300 Mbps трафика, несмотря на то, что в тесте были загружены , но по очереди, все ядра устройства. Но вот на новом устройстве RB4011, процессор которого не намного более производительный, чем на других устройствах Микротик, мы вдруг неожиданно увидели что генерируемый TCP трафик вырос не много , не мало - сразу в 3-4 раза. Это произошло за счет того, что Микротик , по всем внешним признакам ,совершенно определенно стал выполнять на нескольких ядрах не одно приложение BT, а несколько копий BT, каждое со своим отдельных стеком TCP. Это привело к следующему: 1) потери пакетов TCP и снижение размеров окна стека TCP ( количество пакетов в одной засылаемой в канал пачке ) одного стека, что приводит к снижению скорости TCP потока, мгновенно компенсируется увеличением размеров окна других стеков на других исполняемых копиях BT и компенсацией снижения скорости трафика на одном стеке восполнением трафика на других стеках. 2) тестируемый канал не простаивает во время ожидания ответа ACK - подтверждения успешного приема пачки TCP пакетов. Пока один стек ждет ACK, другие стеки заполняют канал своим трафиком . 3) дуплексный TCP тест не является таковым, потому что образуется из двух противоположных симплексов, выполняемых последовательно в разные моменты времени различными копиями ( приложениями, )тестера . То есть ситациция аналогична тому, как это происходит в описанных выше тестах в многозадачной ОС или виртуальных машинах. Фактически мы в тестах TCP имеем работу с совершено иным синтезированным суммарным стеком протокола TCP, отличающимся от стека TCP BT одноядерного устройства и, главное, от стека TCP реального трафика. Фактически такой тест в реализации на RB4011 хотя и остался TCP , но потерял свою информативность о потерях в канале и задержках в подтверждении успешности в доставке пакетов и фактически стал идентичен UDP. Это легко увидеть протестировав канал RB4011 пакетами UDP и TCP, и результаты этих тестов будут близки. А в правильных тестах скорость TCP должна быть как минимум меньше UDP на 10-15%. И чем больше потерь в канале, тем больше разница. Также то, что в ВТ RB4011 работают несколько стеков TCP видно по пакетной нагрузке. Пакетная нагрузка обратного канала трафиком ACK в симплексном правильном TCP тесте и реальном живом TCP трафике обычно составляет 30-35 %. В случае RB4011 эта цифра превышает 60%. Тем самым, предварительные исследования показывают, что новый генератор TCP теста Bandwidth Test на многоядерных Микротик ( следует ожидать такое поведение BT и на других устройствах МТ) по всем признакам стал неадекватно тестировать канал TCP тестом. Поэтому до подтверждения или опровержения данного поведения со стороны компании Микротик, других результатов независимых исследований другими специалистами, просьба воздержаться от ликований при получении очередных фальшивых рекордов и ложных выводов о якобы высокой пропускной способности оборудования, на основе результатов, полученных на RB4011.

Вы ничего не поняли. Объясняю еще раз в чем есть ошибка ( фокус) в тесте здесь некоего anp/hsw и поэтому в тестах получен неправильный результат работы Rocket 5AC Объясняю просто, как для солдат и матросов. Тест iperf TCP через радиоканал между двумя PC на Linuх на столе. На каждой стороне линка в разных задачах ( процессах) Linux поднят сервер и клиент Iperf. В каждую сторону одновременно запущен тест TCP simplex Ipref server-> client. Получено в 40 МГц по 150 Mbps в каждую сторону. Как бы похоже на дуплексный тест и поэтому результат складывается 150+150=300 Mbps в 40 МГц. Типа супер! Однако в тесте есть ошибка. Суть в том, что сервер и клиент Iperf работают в разных задачах многозадачной операционной системы Linix c разделением использования ресурсов процессора и интерфейса Ethernet по времени. То есть каждой задаче ( процессу ) для работы выделяется квант времени и поэтому сервер и клиент Iperf на одном компе работают по очереди. Тем самым тестовый трафик в прямую и обратную сторону канала занимает канал по очереди ( не одновременно в каждый момент времени). Тесты симплексные , но в данным случае два запущенных одновременно симплексных теста в противоположные стороны не образуют дуплекс, поскольку фактически тесты идут по очереди с разделением времени. Суммировать результаты симплексных тестов для получения дуплекса в данном случать делать нельзя и результат ошибочный. Я надеюсь , что на этот раз понятно в чем в тестах есть ошибка (трюк) и просьба не ссылаться более на эти эти фальшивые тесты, как доказательство высокой скорости канала на Rocket 5AC Airmax.

Вы не понимаете физики радио и впариваете своим потребителям неработающий продукт. Три Рокета могут теоретически работать на одну антенну, или три в одном корпусе, только в случае их GPS синхронизации. На это видимо и рассчитывали, когда проектировали эту антенну. Но синхронизация на Рокетах не работает, поэтому не работает эта схема и эта антенна. А если какие то пионеры это берут и ставят, то они не понимают как система должна работать и что они с нее получают .

Потому что N=3, три Рокета на одну антенну.

Какой тарифный план можно дать клиенту определяется загрузкой сектора в прайм тайм. До отключения спутниковых каналов такая загрузка была примерно 0.8-1.2x N Mbps, где N -количество клиентов на сектор. Например при 60 клиентах 0,8-1,2= 50-70 Mbps. Учитывая, что в 20 Мгц емкость сектора ePMP1000/2000 на 60 клиентах равна 90 Mbps UL+DL, то есть 80 Mbps в DL, то тариф 10-15 М это потолок в 20 МГц. Если база синхронизируется и работает в TDD 25/75, то емкость в DL до 65 Mbps. Тогда в 20 Мгц действительно получается тариф не более 5-10М. Сейчас в прайм тайм мы уже имеем случаи загрузки до 1.5XN ( люди смотрят ТВ) , а это загрузка сектора на 60 клиентах до 90 Mbps и поэтому работать желательно в 40 Мгц, где емкость сектора DL 115 Mbps. Сейчас учитывая новые реалии и прогноз дальнейшего роста трафика имеет смысл переходить на ePMP 3000. Камбиум предлагает (гарантирует) только высокую определенную емкость сектора , которая зависит как клиенты работают- на каких сигналах и модуляциях. А вот какой дать клиентам тариф зависит от загрузки сектора трафиком и клиентами . Я указал средние цифры, но у каждого провайдера свои реалии и может быть другая картина . Ну а ПОН - тоже вариант. Однако там есть свои грабли. И не только в технике , а именно в бизнесе, где "кохают" извращенным способом, но в этом случае не ты, а тебя и за твои же деньги.

И на что пал ваш выбор? Как работает?

Первая и основная причина GPF MISS -сильные помехи в канале управления CPE. Это проблема не является специфичной для Elevate, она иногда проявляется и на родных СПЕ и давно известна. В серии ePMP 1000/2000 ее практически извели ( путем повышения помехоустойчивости канала управления) и ее уже давно не видели в 5 Ггц, По крайней мере жалоб от провайдеров с 2-3 тыс CPE Elevate не слышно . В 3000 серии на Elevate CPE на прошивке 4.4.3 ( на которой обеспечена совместимость Elevate UBNT M5 c ePMP 30000) она не часто, но стала появляться Давайте разберемся с возможным источником проблемы и исключим возможную первопричину. Скажите пожалуйста , а что именно работает рядом в трех метрах от базы ? Какая секторная антенна используется на БC? Покажите скрин СА этой базы ( это ePMP 3000L и там отличный информативный CA) а также скрин eDetect базы скана эфира базы и клиента ( скан тоже делается с базы) . У вас падает периодически только этот СПЕ? Остальные работают нормально? У вас на базе стоит short guard интервал? И СА на базе постоянно включен? Вышла 4.5RC69. Попробуйте обновить по крайней мере проблемный CPE. Вообще попробуйте просто заменить СПЕ на другой ( поменять местами CPE) и посмотреть останется ли проблема ЗЫ Вообще кратковременный дисконект СПЕ из за помехи -извечная проблема ШБД. Помнится в далеком 1997 году, когда еще не было стандарта 802.11, было два типа устройств ШБД - Lucent и Aironet. Стояла задача выбора, что подать для исследования в органы для открытия в Украине диапазона 2.4 Ггц для лицензирования. Aironet был дороже, работал как мост лучше, но были дисконекты с потерей регистрации на несколько секунд из за помехи. Lucent был дешевле, работал на то время похуже ( потом исправился), но главное - не рвал сессию . Поэтому выбрали Lucent и Украина пошла в ШБД другим путем в отличии от России, где тогда выбрали Aironet. Так что мы понимаем проблему :). Все будет норм!

В большинстве случаев дисконекты от БС как родных Force, так и неродных UBNT/Микротик клиентов происходят по причине кратковременной потери управления CPE со стороны базы. В логах CPE можно увидеть SM disassociated from AP[00:04:*****] F=5590 11naht20. Reason: 33 (GPFs MISS). Причина -сильная помеха в рабочем канале. Если отваливаются одновременно все CPE , то помеха на стороне базы uplink. В этом случае источник помехи обычно стоит на крыше рядом с базой и светит в створ антенны БС. Если отваливаются только некоторые CPE. то помеха в DL на стороне CPE или на БС от СПЕ слабый сигнал UL. В 2.4 Ггц это могут быть домашние вайфай роутеры, работающие в доме на той же частоте что и CPE . В 5 Ггц это может быть клиентская станция соседа- конкурента или его магистраль, проходящая через этот CPE . Увидеть эту помеху можно помощью фичи eDetect , которая запускается на БС и показывает мощность сигнала и MAC источника помех как на стороне базы , так и на стороне всех клиентов. Влияние помехи зависит от интенсивности DL трафика источника помехи, то есть может наблюдаться зависимость появления и частоты дисконектов от времени суток. Что делать? Найти источник помехи и устранить ее.

Вполне допустимо живой трафик догружать TCP тестом. Например Iperf или на BT микротик Но не надо пока этого делать на RB4011, c ним нужно еще разобраться.

Штатный суппортер на оф. форуме , некто CloudeSS , сделал калькулятор скорости UBNT на Excel. Там видны формулы расчета. Этот калькулятор можно найти на их форуме. Ищите и найдете :) Так покажите загрузку канала живым трафиком. В чем проблема?

Проблема в том, что CINR файбер измеряет неправильно и неадекватно выставляет свою рабочую модуляцию/. Если помех нет или их мало и SNR =CINR, то проблема не проявляется и линк работает достойно. А вот если помехи есть, то работа линка непрогнозируема. В этом и есть вся суть работы AF5x HD.

Да вот эти тесты, фальшивка. Здесь Проверяем. Все расскажем.

Это 5 GHz, 3x30° HD Sector Antenna - AP‑5AC‑90‑HD. Неужели не помните это чудо? - Breakthrough Design !!! хе, хе ! -Powerful Performance !!! . хи, хи ! -3 x 30° Beamwidth Coverage in a MultiPoint Network !!! Хо, хо ! - Efficient Footprint for Reduced Tower Costs- . Это же надо считать своих кастомеров за дебилов, б*ять. Коню ясно, что это принципиально не может работать, ну никак, ни теоретически , ни практически .Как эту шнягу вообще можно было людям впаривать ? B этом видна вся гнилая суть UBNT и всех ее продуктов. Единственное исключение , что достойно внимания , - серия AF и в частности AF5X/AF5x HD, что и обсуждаем, но и это запороли , погнавшись за удешевлением. Если бы они сделали OFDM FFT 512/OFDMA/ MU-MIMO NxN зашитый в кремний ASIC, а именно так ( кроме MU-MIMO, что UBNT тогда считал нерабочей технологией, а это на самом то деле 5G !!! ), согласно презентации 4 года назад на Wispapaloosa 2016, должен был выглядеть этот чипсет, то UBNT был бы сейчас вне конкуренции. Но этого не случилась. А все остальное в портфолио УБНТ - унылое г*но. Никакие фальшивые тесты , рекорды на столе , ценовой демпинг не отменят результатов практики 10 летней эксплуатации продукции UBNT. Это дешевый мусор для пионеров и дал*бов.

Я вот не пойму, ну зачем говорить о том, что доподлинно не знаешь? Чтобы показать людям свою некомпетентность? Что есть такой мазохизм в самореализации? . В самой простой реализации роуминга клиент ничего не должен уметь, окромя поддержки протокола 802.11x WPA аутентификации при защищенном доступе, что есть в Android, iOS и Windows у всех клиентов.

*бнутый на голову!

Если к каждой точке доступа нет возможности подвести кабель, то это не значит, что это ж-па. И вайфай репитеры, это терминология и решения начала 2000-х . Есть такая технология MESH - соединения в сеть точек доступа между собой не по кабелю, а по радио. Такого соединения не надо бояться или говорить, что это плохо. Емкость сети одного сегмента ( в одном MESH канале) такого соединения на ТД 802.11 AC wave 2 MIMO 4x4- 800 Mbps реальной пропускной способности ( не data rate) в частотном канале шириной 80 МГц. Этого обычно достаточно и ТС для его базы отдыха и всей сети этого точно хватит. Да. Дело в том, что эти устройства могут обеспечивать роуминг для одних клиентов ( которые в частности поддерживают 802.11r/k/v ), а для других нет. И 802.11r -это защищенный доступ 802.11x. Он не работает, если клиент получает открытый доступ в сеть.

Есть определенное недопонимание, что есть вайфай роуминг. Во-первых, понятие бесшовности в вайфай роуминге нет. Если есть роуминг ( roaming или handover) , то он всегда seamlesss - непрерывный, то есть без прерывания связи с сетью, или в вольном переводе на русский - бесшовный. Во-вторых, простое переключение клиента с прерыванием связи - дисконектом клиента от сети на сетевом-транспортном L3/L4 уровне и/или на уровне работы приложений L5) часто ошибочно называют также роумингом ( но типа не бесшовным) , или в народе -псевдороумингом. В принципе этот псевдороуминг нередко работает вполне пристойно и юзеров устраивает , все дешево и как то работает. Однако есть проблема. Роуминг - сделан по стандарту IEEE 802.11***, и он работает должным образом всегда 100% и при любых условиях размещения и взаимодействия точек доступа между собой и с клиентами. А вот псевдороуминг- сделан на костылях,из говна и палок и на каждом типе оборудования по разному. Его главная особенность -он может должным образом работать, а может и нет. И что значит не работать должным образом ? Дело даже не во времени переключения клиента между точками 10, 150 или 700 мс, это часто неважно Роуминг не работает, значит либо клиент вообще НЕ переключается между точками доступа (скажем точнее, например в 90% случаев переключается, в 10% -нет), либо переключается, но с дисконектами 1- 5 секунд. Если это есть - значит роуминга нет. А говорить что роуминг есть , но он не бесшовный - это словоблудие малограмотных пионеров-долбодятлов. Я надеюсь в данном кейсе мы увидим случаи , когда такой вот типа псевдоуминг, реализованный на микротиках, асусах, кинетиках , убиках и др. НЕ работает, а роуминг на Камбиум, Рукусах , Арубе (HP) и др. - работает. И надеюсь мне предоставится возможность объяснить на данном простом примере, в чем есть между этим оборудованием разница , что есть Enterprise, а что нет , и почему на одном оборудовании то, что нужно в задаче, - все работает, а на другом -нет.

На примере данного кейса будет образцово показательный мастер класс как нужно проектировать и строить сети вайфай безотносительно к тому, какого конкретного вендора применяется оборудования. Будут рассмотрены несколько вариантов и особенности решений на разном оборудовании и даны оценки каждому варианту. Ну а срач, он неизбежен, формат форума такой. И он даже где то полезен для дела, но это совершенно другая тема.

Вы опять все передергиваете. Я повторяю, что я сказал выше в теме - все можно точно посмотреть. 1) У меня есть претензии к тестам Airmax. Результат - фальшивка, потому что получен результат a) выше теоретического предела б) выше Капасити. Возможная причина - неадекватность теста RB4011, что нужно проверить. Как проверить, я также сказал. 2) у меня нет претензий к тесту AF5x HD на 3 км на Iperf. Я об этом точно и недвусмысленно сказал выше в теме. Единственное пожелание, хотелось бы в тестах iperf видеть ключи запуска теста. 3) Что касается полки Airmax до 200М то эти данные в том числе получены вами в TCP тестах PowerBeam насколько я помню, 10-12 км. Вы можете эти данные опровергнуть, получив и показав результат TCP тестов, но не на RB4011, потому как к нему есть вопросы, а скажем TCP Iperf или показав живой реальный трафик >200 Mbps DL на любом устройстве Airmax на дальности 5-10+ км. Вот вы внимательно прочитайте каждый пункт, пожалуйста не смешивайте их между собой и покажите имеющиеся у вас результаты , сделанные в соответвии с перечисленными выше условиями.

Хорошо, этот кейс принимается. На 1024QAM это возможно получить, если эта модуляция поднята и стабильно работает. . Но вопрос кода это ЕСЛИ выполняется - остается открыт. Точнее там все ясно, а кому не ясно, пусть пробует.

Там тест выполняется на одном ядре. Там совсем другие ядра. Было где то год назад. Ищите и найдете Результат фальшивый. А причин может быть масса, в том числе ваша некомпетентность, или неадекватность RB4011, что и следует проверить.

Я не хочу углубляться в еще одну мутную тему косяков UBNT.