Jump to content

PTP550 Cambium Networks для 5 Ггц каналов точка -точка


Recommended Posts

15 минут назад, Kiano сказал:

а башкой своей подумал

Так я подумал.

Скажи ты - зачем заглядывать в пакет настолько глубоко, чтоб балансить трафик в засраном эфире? А? :) Чем номер порта и тип протокола в этом поможет?

Edited by Dimkers
Link to post
Share on other sites
  • Replies 670
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Славка, твой выход, трафик не такой, полнолуние, фаташоп, ну или чо там еще, мАлтипоинт, лос энлос, лосось, карась 

Классический пример вашей неадекватности восприятия результатов       Это у вас не тянули 5 лет, а когда показывали пример - глаза закрывали и всякие отговорки придумывали, что это не

А мимозу пробовали? Пока у нас это god-like вариант в любых условиях.

Posted Images

2 минуты назад, Dimkers сказал:

Так я подумал.

Скажи ты - зачем заглядывать в пакет настолько глубоко, чтоб балансить трафик в засраном эфире? А? :) Чем номер порта и тип протокола в этом поможет?

А кто сказал что туда кто-то заглядывает?

Link to post
Share on other sites

А как можно забалансить по

IP packets source address and TCP/UDP port: Source IP & Source TCP/UDP Port;

IP packets receive address and TCP/UDP port: Receive IP & Receive Port TCP/UDP Port;

не заглядывая? У тебя прилетел кадр(он же фрейм), обернутый в кучку оберток. Как узнать порт? Да и зачем в принципе?

  • Like 1
Link to post
Share on other sites
9 часов назад, Kiano сказал:

По паттерну

Чтобы это работало, туда надо впихнуть...  А не давай не так. Давай пруф, что в камбале алгоритм балансировки работает по твоим паттернам :)

Ну и собсно даже вдруг если это так, то раскрой тайну, как идёт сравнение пришедшего кадра с паттерном.

Edited by Dimkers
  • Like 1
Link to post
Share on other sites

Камбиум подтвердил, что QinQ не имеет никаких особенностей балансировки трафика в бондинге 2+0 на PTP550. Балансировка работает обычным образом и там нет проблем. У человека   наблюдается  другая проблема, не связанная с балансировкой бондинга, которой занимается суппорт Камбиум.

Edited by Alver
  • Like 1
Link to post
Share on other sites

Палкан! Это все фигня. Как коммутационная матрица, хардварный ЛАСП, load-balancing и паттерны связаны между собой?

:D

Edited by Dimkers
Link to post
Share on other sites

Обновлен рекорд работы PTP550 в одном ( Link Type 1+0)  канале шириной 80 МГц. Реальный трафик Download  480Mbps + Upload 40 Mbps, режим ePTP.   Всего 520 Mbps UL+DL.

PTP550_load480Mbps.png

Напомню что в двух каналах, в бондинге Link Type 2+0 80+80MHz рекорд   на живом реальном трафике составляет

Download 690  Mbps + Upload 125 Mbps. Всего 815 Mbps UL+DL. Разделение трафика  между каналами  примерно поровну.

 

TP550_690_125M_80_80MHz.png

Edited by Alver
Link to post
Share on other sites

       Следует отметить, что такой реальный трафик может пропустить на сегодняшний день  Cambium PTP550,  а также Force 325/300 CSM (в одном канале 80МГц) благодаря аппаратной акселерации, реализованной в чипсете   Atheros 802.11ac wave 2.

      Чипсет предыдущего поколения Atheros 802.11ac  wave 1 не имеет в радио аппаратной акселерации, поэтому потолок реального трафика  оборудования (  UBNT, MikroTik) на данном чипсете  составляет 220 Mbps в 40 МГц и 250  Mbps в 80 МГц . При этом в синтетических тестах  UDP/TCP  ( пакеты данных  без агрегации и фрагментации ) оборудование на Atheros 802.11ac  wave 1  может показать высокий результат, но на реальном трафике мы  имеем совсем другую картину.

     Что касается  старого ( 10 летней давности) оборудования 802.11n, то там полка  реального трафика составляет 140-160Mbps в 40 МГц из за низкой пакетной производительности  ( порядка 25-28k pps) платформы Atheros AR9344/AR9350 ,  на котором построено оборудование  802.11n большинства вендоров. При этом в  тестах можно видеть 220 Mbps UL+DL,  что недостижимо на реальном трафике. 

   Также мы рассчитываем , что высокую реальную скорость ( порядка 1  Gbps в 80 МГц на 1024QAM) покажет Force 400   на платформе 802.11ax ( Wi-Fi 6), который выйдет на рынок очень скоро.  

Edited by Alver
Link to post
Share on other sites
В 11.11.2020 в 16:09, Dimkers сказал:

Так я подумал.

Скажи ты - зачем заглядывать в пакет настолько глубоко, чтоб балансить трафик в засраном эфире? А? :) Чем номер порта и тип протокола в этом поможет?

Я вот шото не пойму: при чем порты и протоколы вообще?

Мне как бы пох%#, какие там алгоритмы у камбалы и мимозы, пруфы хуюфы, мне фиолетово. Тебе нужно - ищи.

Для сравнения по паттерну или по сигнатуре не нужно никуда заглядывать.

Не понял? Мне пофиг, доказывать не буду, думай что я не прав.

Link to post
Share on other sites
16 часов назад, Kiano сказал:

Я вот шото не пойму: при чем порты и протоколы вообще?

Мне как бы пох%#, какие там алгоритмы у камбалы и мимозы, пруфы хуюфы, мне фиолетово. Тебе нужно - ищи.

Для сравнения по паттерну или по сигнатуре не нужно никуда заглядывать. 

Не понял? Мне пофиг, доказывать не буду, думай что я не прав.

Ни нервничай :)

Порты и протоколы тут при том, что балансится у камбалы по....

Для сравнения по паттерну нужно выполнять трудозатратные действия. Т.е. брать кадр и сравнивать. Что-то с чем то. Это более затратная операция для железки, чем чётный влево, нечётный вправо. Это сродни тому, что на слабых железках тест tcp показывает меньшую скорость, чем udp. Казалось бы. Пакеты передавать в обоих случаях же. А нет...

 Не понял? Мне тоже пофиг :) Я и так тут много рассказал.

Ну и собсно как сравнение по паттерну влияет на алгоритм балансировки - никто так и не ответил :)

Вообще для проверки качества работы каналов нормальные люди генерят и шлют проверочные синхропакеты с интервалом(bfd тому пример). И чем важнее канал, тем чаще шлют для проверки, жертвуя частью пропускной способности канала. Если канал плохой, то часть теряется и на основе числа потерь уже используются очереди и коэффициенты распределения пакетов по каналам. Таким образом можно делать суммирование или резервирование. Но это уже другая история.

Edited by Dimkers
Link to post
Share on other sites
6 часов назад, Dimkers сказал:

Ни нервничай :)

Порты и протоколы тут при том, что балансится у камбалы по....

Для сравнения по паттерну нужно выполнять трудозатратные действия. Т.е. брать кадр и сравнивать. Что-то с чем то. Это более затратная операция для железки, чем чётный влево, нечётный вправо. Это сродни тому, что на слабых железках тест tcp показывает меньшую скорость, чем udp. Казалось бы. Пакеты передавать в обоих случаях же. А нет...

 Не понял? Мне тоже пофиг :) Я и так тут много рассказал.

Ну и собсно как сравнение по паттерну влияет на алгоритм балансировки - никто так и не ответил :)

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

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

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

Link to post
Share on other sites
12 часов назад, Kiano сказал:

Да, мимоза так умеет. Но есть но: порт, с*ка порт и еще раз порт.

А так - железка супер

Ага.  В мимозы порты, в камбалы свои приколы.  Ну как так может быть, стоял линк год, кушать не просил.  Теперь при перезагрузке коннектится по радио по 20 минут. Смена прошивок и частот результатов не дала. При коннекте сигнал -48.   Никаких изменений по питанию, кабелям, etc не производили.  Ну какого х..я оно так?    

Link to post
Share on other sites

  линк на мимозе больше двух лет проработал затем лан ушол в 100мб - все танцы с бубном прошли пока не поменяли на новую это про B5c 

Edited by adik_v
Link to post
Share on other sites
1 час назад, Kiano сказал:

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

Чисто практически, чётный и не чётный делается простым : если 1 то влево, иначе вправо. Все. А переваривать в коммутации по паттерну - трудозатратные вещь и сравнима с case.  Это уже дело не коммутаторов, а роутеров или какихнить dpi. Кстати именно поэтому в микротике, например том же rb4011 на arm(да и не только микротике) при увеличении числа правил в фаерволе(iptables) падает производительность. Потому как это, повторюсь - трудозатратная операция.

 

И собсно зачем делать разделение трафика в радиоканалы по tcp/udp - загадка для меня, с головой достаточно делать как в lacp - по mac или ip. Тем более что в самой камбале нет крутилок на этот счёт.

Link to post
Share on other sites

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

Link to post
Share on other sites
54 минуты назад, Kiano сказал:

логика разделения опираясь на тсп есть: не разносить один коннект на разные каналы

а это разве будет разносить:

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

достаточно делать как в lacp - по mac или ip

 

Link to post
Share on other sites
3 часа назад, Kiano сказал:

не разносить один коннект на разные каналы, например

Ну глупость же. Ей богу. Ну даже если полетит у тебя пакет одному адресату разными каналами. И что?

Не, эта тема смотрю далеко ушла от самого православного радиобарахла... Дальше можно продолжать, но не пальцем в небо. Ты хоть бы почитал про очереди и проверку последовательности пакетов....

Link to post
Share on other sites
1 минуту назад, Dimkers сказал:

Ну глупость же. Ей богу. Ну даже если полетит у тебя пакет одному адресату разными каналами. И что?

Не, эта тема смотрю далеко ушла от самого православного радиобарахла... Дальше можно продолжать, но не пальцем в небо. Ты хоть бы почитал про очереди и проверку последовательности пакетов....

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

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

а это разве будет разносить:

 

Конечно не будет.

Но здесь будет узкое место: не получится утилизировать всю полосу обоих каналов одним соединением. Это если по маку и ипу. Как оно по факту у камбалы/мимозы - хз, может так и есть

Link to post
Share on other sites
1 час назад, Kiano сказал:

Но здесь будет узкое место: не получится утилизировать всю полосу обоих каналов одним соединением

Так это же узкое место будет при разнесении по порту :) Ну как ты раскинешь https? :)

Оптимальный вариант - чётный влево, нечётный вправо. Все.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content


×
×
  • Create New...