Перейти до

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


Рекомендованные сообщения

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

Но дело не в этом

Дело в том, что в предмете вы поплыли.

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

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

У Камбиум аппаратно-программная, у свичей коммутация аппаратная, агрегация -программная.

Ржу Бл#. Ты хотя сам понял шо написал?

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

у них разные механизмы. 

У них разные рукажопы код пишут. да? В блялинке осилили, а в камбиуме - ну не шмогла....

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 714
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

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

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

Posted Images

Опубліковано: (відредаговано)
21 минуту назад, Dimkers сказал:

Дело в том, что в предмете вы поплыли.

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

Ржу Бл#. Ты хотя сам понял шо написал?

У них разные рукажопы код пишут. да? В блялинке осилили, а в камбиуме - ну не шмогла....

 

У них задача вообще разная. Камбиум PTP550  трафик делит между каналами, а свичи - наоборот объединяют каналы.

Свичи Камбиум нормально  делают агрегацию LACP.

В радио PTP550 задача обратная- разделить трафик по меткам между каналами.

ЗЫ

Программисты длинк ничего в LACP   не делают. Бинарный код LACP и др. входит в SDK свича.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах

Ты дебил? Объясню на пальцах.

 

порт 10G свич - (порт LACP из 2*1G<->порт LACP из 2*1G) - порт 10G свич

Свич порт 1G - камбиум порт 1G <-> (камбиум 2 радиоканала WiFI) <-> камбиум порт 1G - свич порт 1G

 

9 минут назад, Alver сказал:

Программисты длинк ничего в LACP   не делают. Бинарный код LACP и др. входит в SDK свича.

А что делают програмисты камбиум?

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах

Я правильно понял что PTP550 балансит трафик основываясь на маках, тогда ни по барабану ли в каких вланах эти маки.
Или тут свой какой-то уникальный алгоритм разделения ?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
47 минут назад, mdbo сказал:

Я правильно понял что PTP550 балансит трафик основываясь на маках, тогда ни по барабану ли в каких вланах эти маки.
Или тут свой какой-то уникальный алгоритм разделения ? 

Деление  не по MAC . Если я где то ранее говорил про MAC, то это было  в ранних версиях, сейчас этого нет.

  И там точно уникальный алгоритм  именно разделения трафика  по 2-м  каналам  Load balancing , а не агрегации 2-х каналов в один .

Метки разделения

Transport layer of OSI model protocol type: TCP/UDP;

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;

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, Alver сказал:

И там точно уникальный алгоритм  именно разделения трафика  по 2-м  каналам  Load balancing , а не агрегации 2-х каналов в один .

Да? И какой же он уникальный???

5 часов назад, Alver сказал:

Если я где то ранее говорил про MAC, то это было  в ранних версиях, сейчас этого нет.

Так это было пару дней назад. е&#036;#ть у вас скоростя...

Даж на прошлой странице твоей пук был:

 

Цитата

Агрегация в PTP550  проводится на L1 ( радио) /L2 (  MAC)  уровне.

5 часов назад, Alver сказал:

Метки разделения

Это поэтому проц укатывается в полку?

Т.е. пришедший кадр со свича дерибанится аж до TCP и потом разделяют?

Дебилы шоль?

 

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Dimkers сказал:

Да? И какой же он уникальный???

Так это было пару дней назад. е&#036;#ть у вас скоростя...

Это поэтому проц укатывается в полку?

Т.е. пришедший кадр со свича дерибанится аж до TCP и потом разделяют?

Дебилы шоль?

 

Вот ты бы перестал популизмом заниматься, а башкой своей подумал. Каждый чейн имеет разные показатели потерь, ошибок и прочей ебатории. А теперь задумайся, какой п@зд#ц был бы, если применить здесь алгоритмы из эзернет сетей, где потери ноль целых х#&#036; десятых.

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

Я раньше пробовал 2 линка с разносом в 700мгц объединять в лаг, и нихера оно не работало. Хуже чем каждый отдельно.

Відредаговано Kiano
Ссылка на сообщение
Поделиться на других сайтах
15 минут назад, Kiano сказал:

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

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

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

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, Dimkers сказал:

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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
Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, Kiano сказал:

По паттерну

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

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

Відредаговано Dimkers
  • Like 1
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

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

Відредаговано Alver
  • Like 1
Ссылка на сообщение
Поделиться на других сайтах

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

:D

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Обновлен рекорд работы 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

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

       Следует отметить, что такой реальный трафик может пропустить на сегодняшний день  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), который выйдет на рынок очень скоро.  

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
В 11.11.2020 в 16:09, Dimkers сказал:

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
16 часов назад, Kiano сказал:

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

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

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

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

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

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

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

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

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

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

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×
×
  • Створити нове...