[LostSoul]

48 минут назад, slv700 сказал:

Зачем же нам нужны ваши тесты на столе, причем не в Nv2, а в стандартном вайфай CSMA, где родные драйверы Atheros на офисе ( на столе ) конечно же выдают 480M в 80 Мгц.

 

затем что кое-кто не писал бред про ограничения в 200МБит , которых нет.

Режим включен nv2 .

 

 

21 минуту назад, slv700 сказал:

Это платформа ARM , на нем плохо работает Nv2.  Причина как раз в видимо в том, что Микротик не смог реализовать на Nv2  параллельную    обработку трафика на 4-х ядрах   IPQ 4018 ( 802.11ac). 

В общем случае на ARM все работает гораздо лучше, распределение по ядрам есть. 

Но в определенных сложных ситуациях сбоит и требуется ручное вмешательство чтоб исправить ситуацию, ибо сыровато

 

 

21 минуту назад, slv700 сказал:

а именно в оптимизации распределения трафика пакетов  разной длины и типов  в очередях на обработку пакетов.  

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

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

 

 

[slv700]

2 часа назад, gothkiller сказал:

force300-25.

У него 4 ядра ARM Cortex. Там все в порядке и в тестах и на реальном трафике. В 40 МГц он пропустит 315  Mbps UL+DL. В 80 МГц - немногим более 400Мbps.  Нужно больше реального трафика, тогда нужен более производительный Force 300 CSM или PTP550.

17 января будет презентация Force 400  серии ( 4-е ядра  Сortex IPQ8072 802.11ax). На нем получено 450+ Mbps реального трафика в 40 МГц.  Результаты испытаний скоро будут выложены.

ЗЫ

Забудьте уж наконец про этот отстой  из оборудования , отставшего на два поколения wireless технологий. Этот мусор годится    разве  что замылить тестами клиенту глаза, чего собственно невменяемый товарсч и не скрывая хочет сделать.

 

 

[LostSoul]

3 минуты назад, slv700 сказал:

Забудьте уж наконец про этот отстой  из оборудования , отставшего на два поколения wireless технологий. Этот мусор годится    разве  что замылить тестами клиенту глаза, чего собственно невменяемый товарсч и не скрывая хочет сделать.

Типа надо бежать за модным хипстерским смузи?

Серверные версии Linux тоже отстают от бытовых хипстерских Ubuntu на 2 поколения ,  но все адекватные админы ставят именно их.

Как стабильные и проверенные.

Пример попытки бежать за "новым и хипстерским" типа LTU показывает что весь этот маркетинговый пшик про инновации пока еще нихрена не работает как надо.

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

 

 

[slv700]

19 минут назад, LostSoul сказал:

Но в определенных сложных ситуациях сбоит и требуется ручное вмешательство чтоб исправить ситуацию, ибо сыровато

Идиотизм.

 

19 минут назад, LostSoul сказал:

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

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

 Кто спорит что на MIPS один процессор и ничто никуда не раcпределяется? 

Какая  упаковка? Дело не в ппс.  И никак упаковка не не повысит скорость если нет полки по ппс. А ее там на трафике 200М нет. И вообще упаковка пакетов в Ethernet мало что дает ( пакеты в wireless  по любому фрагментируются в размер порядка 2000 байт) , это  тупиковый путь пионера-любителя.

[LostSoul]

Только что, slv700 сказал:

Идиотизм.

Конечно, лучше как в UBNT что просто ничего не работает и ничего не поправить, а только снять, выкинуть и поставить Mikrotik

 

[slv700]

5 минут назад, LostSoul сказал:

Типа надо бежать за модным хипстерским смузи?

Серверные версии Linux тоже отстают от бытовых хипстерских Ubuntu на 2 поколения ,  но все адекватные админы ставят именно их.

Как стабильные и проверенные.

Пример попытки бежать за "новым и хипстерским" типа LTU показывает что весь этот маркетинговый пшик про инновации пока еще нихрена не работает как надо.

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

 

 

Пока мы видим только только вашу некомпетентность. И ваши ложные выводы из ваших неадекватных экспериментов.   

[LostSoul]

1 минуту назад, slv700 сказал:

это  тупиковый путь пионера-любителя.

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

 

а мы просто ставим одноядерный микротик и получаем 500мбит нашего профиля трафика   ( и 300мбит вашего профиля трафика ) без всяких извращений

 

 

Только что, slv700 сказал:

Пока мы видим только только вашу некомпетентность. М ваши ложные выводы из ваши мутных неадекватных экспериментов.   

когда вместо сказок про "не предусмотрено отделом маркетинга производителя"  будут представлены факты про разницу между rocket LTU и LTU-PRO  ,  тогда будем подвергать сомнению верность методики теста.

 

[slv700]

52 минуты назад, LostSoul сказал:

распределяющий пакеты по очередям , для чего ему требуется целых 4 ядра с аксселератором это путь пионера-любителя.

Это путь Qualcomm-Atheros и всех  производителей современных платформ для wireless  ( кроме  UBNT :) и не только.

Только вы застряли на Микротике 10 летней давности.

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

    Но есть один подтвержденный  испытаниями на многих платформах и вендорах факт.

       Для скоростей выше 200-250Mbps реального трафика в wireless  нужен мощный и дорогой процессор с  одним ядром или относительно бюджетный  многоядерный процессор. Но во втором случае нужно оптимально распределять трафик между ядрами процессора. Atheros-Qualcomm это делает в своих  драйверах. Но при применении проприетарных протоколов в устройствах ШБД  необходимо   родной драйвер Atheros совместить с этим протоколом.

Микротик с  Nv2 на многоядерном ARM c этой задачей не справился. Попытки в течении 3-х лет  сделать это не дали результат.

UBNT 5AC Airmax вообще эту задачу не ставил,  и похоже сумел   пробить полку   на одноядерном процессоре Atheros 720MHz ( Рокет Gen2) на новых прошивках, но похоже  только на синтетическом тестовом трафике  пакетами постоянной длины. Как это  работает  на реальном трафике пока убедительных данных нет.

На сегодняшний день такая задача решена  на многоядерных платформах  только Камбиум  и на одноядерном/многоядерном CPU- Radwin, Redline ( а также на уже несуществующей Мимозе) .  Полка в 400М также пробита LTU на AF5X HD. Может ли  одноядерный LTU выдать больше? У кого есть такие данные- показывайте. 

        Cambium на многоядерной платформе  ARM  держит реальный живой трафик не менее  800 Mbps. Скоро это покажем.

[LostSoul]

1 час назад, slv700 сказал:

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

Знания о сетевых технологиях носят системный характер и не привязаны к конкретному вендору или классу устройств.

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

И во всех случаях это будет приводить к увеличению задержки передачи пакета.

Хоть гламурный маркетолог назовет это packet packing ,  хоть "очередями с акселератором" ,  суть не меняется.

 

Для синхронного TDM-подобного канала без упаковки пакетов в кадры,   производительность в битах(мегабитах и.т.п ) всегда будет равна PPS * на средний размер пакета.

То есть ( приблизительно ) , один и тот же TDM канал без упаковки, выдает  500мбит/c на размере пакета 1500байт , 166МБит на размере пакета 500 байт , и 17Мбит/c на размере пакета 54 байта.

Рассуждения про какой-то там "реальный трафик"  без конкретики это ложь,  трындеж   и провокация.

 

Очевидно, что нагрузку на канал могут формировать разные виды трафика.

Если это игровой клуб на 500 посадочных мест , где проводится международный чемпионат по Counter Strike, то средний размер пакета будет <250 байт  и пропускная способность  около 20-25 МБит/c.

 

Если это гостиница,  в которой 90% нагрузки формируют Smart-телевизоры ,   загружающие OTT потоки пакетами по  1450 байт ,   то и пропускная способность будет 483МБит из 500 полученных для "полного кадра".

 

Реальный профиль трафика для домашних подключений при количестве 20-50 абонентов на вынос показывает что средний размер пакета примерно в районе 1350 байт ,   таким образом 500мбит  измеренных "по тесту" превратятся в 450мбит  по "графикам интерфейсов".

 

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

 

Поэтому "замылить глаза клиенту" никто не пытается, клиенту демонстрируют реальную скорость загрузки файла из сети Интернет , достижимую на практике.

 

В случаях же "иного использования"  ( кроме передачи файлов или высокоскоростных потоков данных ) клиенту в принципе не важна  скорость.

 

Допустим клиент купил 300мбит/с безлимитный тариф. А  я "в уме" перечитал это как 25 тысяч пакетов в секунду , потому что вместо охрененного камбиум с электролитами очередями и акселераторами купил себе "пионерский" микротик.

При загрузке файлов клиент увидит свои честные 300мбит.

А что если он решит поиграть в CS?

Трафик от одного игрока - аж целых 3 пакета в секунду.

Таким образом, купленного тарифа клиенту хватит аж на 8333  игроков , играющих одновременно у него дома.

Замылил ли я глаза клиенту,  если не предупредил его,  что 8 тысяч игроков из его квартиры играть смогут,  а вот 133 тысячи ( с игровым трафиком 300мбит ) уже не смогут?   Видимо я очень недобросовестный провайдер.  Надо покупать камбиум и жить не по лжи.

 

 

 

 

 

[slv700]

Мы говорим не о подключении одного клиента ( для этого есть дешевые CPE) , не о подключении гостиницы с вайфай раздачей, не о видеонаблюдении и прочее, -это все частные случаи.

Общий случай - задача  построения бекхола-  магистрального канала (например  аплинка в поселок)  пропускающего   400+ Mbps реального трафика, который в этом  например поселке потребляется  по статистике 300+ юзерами ( дома в частном секторе) с пакетной нагрузкой  in+ out опять же по статистике   порядка до 60k pps . Как подключены юзеры  в распределительную сеть в поселке  по радио или ПОН не имеет значения. Параметры  трафика  от этого не зависят.

   С этой задачей справляется универсальное решение, например на Сambium Force 300/400  или PTP550.  В частных отдельных случаях с задачей может справится     современный CPE  например от  UBNT или устройство типа Микротик 10 летней давности, что само собой обойдется дешевле.

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

[LostSoul]

57 минут назад, slv700 сказал:

Для скоростей выше 200-250Mbps реального трафика в wireless  нужен мощный и дорогой процессор с  одним ядром или относительно бюджетный  многоядерный процессор. Но во втором случае нужно оптимально распределять трафик между ядрами процессора.

 

Микротик с  Nv2 на многоядерном ARM c этой задачей не справился. Попытки в течении 3-х лет  сделать это не дали результат.

UBNT 5AC Airmax вообще эту задачу не ставил

Опять ложь, звездежь и натягивание совы на глобус.

 

Допустим что распределение трафика по ядрам это хорошо и замечательно ( что не так , так как рождает ряд дополнительных проблем ) .

Но зачем врать, будто бы без супер технологий этого не происходит совсем?

 

Проблемы с распределением обработки пакетов по ядрам процессора исходно существовали только для обработки множества пакетов С ОДНОГО интерфейса.

 

То есть, допустим ,   одно ядро у нас обрабатывает 350 Kpps ( 500мбит/1500байт , 166мбит/500байт,  17мбит/54байт , что там у вас "реальный трафик" подставьте сами ).

Но трафик то идет в 2 направлениях, и с распределением по ядрам потоков download и upload ни на одной платформе проблем не было никогда, ибо прерывания и интерфейсы разные.

Соответственно даже самая кривая и недоделанная платформа, имея 2 ядра прокачает  350kpps  в одну сторону, и 350kpps в другую сторону ( то есть на пакетах 1500 байт суммарно in+out  500+500 = 1ГБит )

Так является ли это указанное приемущество Cambium реально востребованным?  Сомнительно.

Как сомнительно и то, что на Mikrotik ARM до сих пор  не сделано распределение очереди пакетов с одного интерфейса по ядрам.

 

и да, откуда slv700 взял что в LTU стоит одноядерный процессор?

 

по cpuinfo выдает что там вполне себе двухядерный процессор MIPS частотой 2ГГц

 

 

абсолютно одинаковый процессор стоит, что в rocket ltu , что в ltu pro

 

 

 

 

4 минуты назад, slv700 сказал:

400+ Mbps реального трафика, который в этом  например поселке потребляется  по статистике 300+ юзерами

это фантастика.

из 300 пользователей у 200 будет стоять дома 1-2 ТВ-приставки с какой-нибудь смотрешкой.

Из этих 200 , минимум 50 будут регулярно забывать выключать ее на ночь вместе с телевизором,  поэтому трафик от 300 домохозяйств не может быть ниже 225 мбит практически никогда, если это живые абоненты а не мертвые души.

 

[LostSoul]

Пошел, проверил информацию.

Да,  входящий трафик с каждого интерфейса на mikrotik arm  , похоже обрабатывается только на своем отдельном ядре.

но есть маленький нюанс,  от трафика в 100мбит это самое ядро загружается аж на целых 10%

 

к сожалению нету возможности проверить, насколько линейно растет нагрузка,  но если линейно, то получается что на радиомосту с 2 интерфейсами  , одно ядро выжимет 1ГБит с проводного интерфейса , второе ядро 1ГБит с радиоинтерфейса. 

 

Из чего следует, что проблема , озвученная, slv700 высосана  из пальца и надумана,  ради продажи своего мусора.

 

Указанное ограничение может стать узким местом, в случае если устройство несет дополнительный функционал типа NAT, шейпера , netflow ,  прозрачного моста для существенного количества ( сотни ) mac-адресов.

В случае L3 моста , когда с каждой стороны канала виден только один единственный MAC , озвученное ограничение не актуально полностью.

 

 

[LostSoul]

42 минуты назад, slv700 сказал:

пропускающего   400+ Mbps реального трафика, который в этом  например поселке потребляется  по статистике 300+ юзерами ( дома в частном секторе) с пакетной нагрузкой  in+ out опять же по статистике   порядка до 60k pps .

так мы выяснили уже , что одного ядра Mikrotik ARM достаточно чтоб обработать 83k pps в одну сторону.  и второго ядра чтоб обработать 83k pps в другую.

нахрена нам ваш камбиум?

 

[slv700]

1 час назад, LostSoul сказал:

так мы выяснили уже , что одного ядра Mikrotik ARM достаточно чтоб обработать 83k pps в одну сторону.  и второго ядра чтоб обработать 83k pps в другую.

нахрена нам ваш камбиум?

 

Вам уже 10-й раз говорят , что полка 200-220М на живом трафике  имеет место быть не из за ограничения пакетной производительности той или иной платформы. Пакетная нагрузка живого трафика 200  Mbps  по статистике  не превышает 35k pps и по ппс с ней справляется ЛЮБАЯ платформа на 802.11ac.

  Полка 200-220М  вызвана другой  причиной, -  потому что одноядерному процессору Atheros 720 МГц на платформе MIPSBE 802.11 ac не хватает производительности обработать трафик свыше 200-220М, состоящий из пакетов разной длины для фрагментации и пакинга их в фреймы в радио длиной от 2000 до 3200 байт   в случае  применения протокола Микротик Nv2/Nstreme. При этом синтетические тесты с пакетами фиксированной длины  не  имеют этой полки.

  При применении Микротик   на протоколе  Nv2 на 4-х ядерной платформе ARM Corteх  802.11ac также есть полка в пропускной способности, которая даже  меньше 200 Mbps. Причина та же. Одно ядро Сortex не тянет нагрузки в  NV2  живым трафиком в симплексе больше 150М. А задействовать 4 -е ядра Сortex ARM    в NV2  программисты Микротик не смогли ( или не захотели тратить на это ресурсы).

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

     В качестве нормального и правильного эксперимента возьмите  типовой  канал - аплинк, например на оптике,  в село  скажем  на дальности 10+ км с трафиком в прайм тайм например  400+Mbps и попробуйте переключить оптику на радиоканал.

В качестве радиооборудования  попробуйте

1) Микротик   802.11ac на  MIPSBE ( типа QRT 5)

2)  Микротик   802.11ac на   ARM (  типа  LDF 5 )

3) Litebeam 5AC  802.11ac

4) Rocket 5AC Gen 2  802.11ac 

5) AF5x HD  (LTU)

6) Cambium 300CSM/325 ARM 802.11ac wave2

7) Cambium PTP550  ARM 802.11ac wave2

8) Cambium Force 400C/425 ARM 802.11 ax.

И вы сами увидите , что реальный трафик 400М  пропустит только  AF5x HD   и любой  Сambium. Причем средняя задержка в канале  на таком трафике  не будет  существенно расти. И тогда, наконец , прозрете зачем и кому нужен Камбиум.

[LostSoul]

1 час назад, slv700 сказал:

для фрагментации и пакинга и

так у адекватного провайдера это ВЫКЛЮЧЕНО.

пакет отправляется "как есть" , размером от 54 до 1500 байт без какого-либо пакинга.

а 3200 байт это вы вообще с nstream перепутали, и вот там да, нагрузка на процессор растет сильнее.

 

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

 

 

1 час назад, slv700 сказал:

В качестве нормального и правильного эксперимента возьмите  типовой  канал - аплинк, например на оптике,  в село  скажем  на дальности 10+ км с трафиком в прайм тайм например  400+Mbps и попробуйте переключить оптику на радиоканал.

давайте сначала на вас мою новую вакцину от короны испытаем :-)

бред.

достаточно прогнать запись трафика указанного поселка .  любым tcpreplay с обоих концов линка.

 

 

 

1 час назад, slv700 сказал:

И тогда, наконец , прозрете зачем и кому нужен Камбиум.

никому он кроме его продавцев не нужен. это давно всем понятно

 

[slv700]

7 минут назад, LostSoul сказал:

так у адекватного провайдера это ВЫКЛЮЧЕНО.

пакет отправляется "как есть" , размером от 54 до 1500 байт без какого-либо пакинга.

а 3200 байт это вы вообще с nstream перепутали, и вот там да, нагрузка на процессор растет сильнее.

 

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

 

 

давайте сначала на вас мою новую вакцину от короны испытаем :-)

бред.

достаточно прогнать запись трафика указанного поселка .  любым tcpreplay с обоих концов линка.

 

 

 

никому он кроме его продавцев не нужен. это давно всем понятно

 

Делайте что хотите.   Я вам все сказал. Если вы не способны понять простые вещи, долбитесь.

[Saab95]

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

 Расскажите, в чем разница между UDP и ТСР-тестом, и заодно приложите скрин дуплексного ТСР-теста.

Разница теста UDP в том, что он не отправляет обратно 65 байтные пакеты подтверждения.

Если запустить 2 теста по UDP, первый гонит пакеты 1500 байт, второй 65 байт - по нагрузке будет то же что и TCP тест.

 

В 09.01.2021 в 14:44, xabarov сказал:

Таких же микротикнутых? :) Для меня показатель - личный опыт и опыт конкурентов, которые строились параллельно с нами в нашем районе на микротиках. Их клиенты уходили к нам из-за более высоких скоростей и стабильности связи, а после прихода оптики они быстро растеряли базу клиентов, в то время как мы еще держимся с минимальным оттоком, т.к. вовремя обновили оборудование и увеличили скорости по тарифам до уровня оптики.

Ага на радио увеличили скорость по тарифам для оптики.

Мы тоже так увеличивали, если на БС 10 человек и по сути не качают. А если радио позволяет прогнать 200М, то 2-3 человека с тарифом 50М вполне могут на ней уживаться, вернее не 2-3 всего, а 2-3 активно качающие.

У нас клиенты никогда никуда не уходили, кроме как на сотовых (обычно с возвращением обратно), или на оптику.

Сейчас так же такое время, что сотовые стали жать со своими интернетами - если в семье 4 человека, это 4 смартфона, платить за каждый 500р. в месяц это уже 2000р. А платить по 1000р. за быстрые тарифы или большие объемы - уже 4000 на семью. Так почему бы не взять тарифы по 300-400р. где малые пакеты интернета, использовать их вне дома, а дома сидеть на провайдере?

[LostSoul]

32 минуты назад, Saab95 сказал:

Разница теста UDP в том, что он не отправляет обратно 65 байтные пакеты подтверждения.

Если запустить 2 теста по UDP, первый гонит пакеты 1500 байт, второй 65 байт - по нагрузке будет то же что и TCP тест.

 

 

Saab95 вы знаете детали про фрейминг в nv2? Есть в действительности какие то проблемы из описанных 700ым?

[NewUse]

Коллеги, а можно вас попросить покинуть топик про LTU и раздел про UBNT и обсуждать теорию где-нибудь ещё, например в разделе Камбиума или в во флуде.

[Saab95]

Ничего там нет такого. Когда только NV2 появился там были несколько ограничений вида не возможности в один поток прогнать большую скорость (например тест по UDP в один поток показывал скорость 150М, а тут же тест в 2 потока показывал 200М), но это в последствии исправили. Сейчас ограничений по скорости и каким-то там упаковкам нет.

 

У нас при работе на L3 имеются каналы где и 350 и 400 мегабит между двумя IP адресами бегают без проблем.

 

[slv700]

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

Ничего там нет такого. Когда только NV2 появился там были несколько ограничений вида не возможности в один поток прогнать большую скорость (например тест по UDP в один поток показывал скорость 150М, а тут же тест в 2 потока показывал 200М), но это в последствии исправили. Сейчас ограничений по скорости и каким-то там упаковкам нет.

 

У нас при работе на L3 имеются каналы где и 350 и 400 мегабит между двумя IP адресами бегают без проблем.

 

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

Что касается работы  Nv2 на ARM -  смотрите на оф. форум Микротик  ARM devices and NV2 protocol. Там дана исчерпывающая картина нынешнего состояния этого вопроса.

[LostSoul]

50 минут назад, slv700 сказал:

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

да уже и унитаз принесли и задницу показали, а все равно недоволен.  ( см анекдот )

 

будет время прогоню зеркальный поток трафика от "много малогрузящих абонентов" - поглядим.

пока никаких описанных проблем не вижу

 

 

[weedman]

2 часа назад, slv700 сказал:

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

Что касается работы  Nv2 на ARM -  смотрите на оф. форум Микротик  ARM devices and NV2 protocol. Там дана исчерпывающая картина нынешнего состояния этого вопроса.

Микрот норм работает за свои бабки. меня выручило то, что там можно скрипты и когда я сталкнулся с проблемой атаки на мак адреса, я нашел какой-то скрипт немного подменил (я вообще ничего в этом не понимаю) и проблема решилась. как бы это дает вполне полезные возможности. С сектора на свежих прошивках 70 мб в 20 слетает при 20+ клиентах  !в хороших условиях! для комфортной работы вполне. 

 

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

802.11N

AC- не понравились, проблема общеизвестна с арм.

Изменено 11 января, 2021 пользователем weedman

[mefer]

Пока нет ни одного реального примера против применения LTU мы смонтировали базовки на башне на 149 метрах от земли перед новым годом, посмотрим как оно покажет себя на клиентах. Смонтировали пока 2 сектора. много белых зон. Но будут клиенты на наших LR и LITE посмотрим реальные характеристики.

[LostSoul]

19 часов назад, weedman сказал:

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

можно расшифровать по русски?