Перейти к содержимому
Калькуляторы

Проповедь про Cambium ePMP 1000 За что я ненавижу Cambium !!!!!

Лучше пойди сразу говна наверни, потому что это пятерка. :)

ну повесь себе орден главного ***бола.....ты его явно заработал.

Поделиться сообщением


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

Лучше пойди сразу говна наверни, потому что это пятерка. :)

ну повесь себе орден главного ***бола.....ты его явно заработал.

 

:)

 

Спасибо поржал. Твое экспертное мнение очень важно для меня, да.

Поделиться сообщением


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

Конечно, видео совершенно не познавательное. Зачем такой большой телевизор, когда хватило бы и ноутбука. И при чем вообще видео, то есть нет смысла тестировать каналы связи просмотром видео, тут тесты более показательные.

 

Любое оборудование заработает в таких условиях, если есть прямая видимость до деревеньки в километре, где БС расположена.

 

У микротика тут было бы явное преимущество - его можно запитать от прикуривателя, а не таскать инвертор.

Поделиться сообщением


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

А Роман утверждает:" Интернет не килограмм картошки", просмотр видео, с ютуба например, позволяет оценить скорость и качество вполне объективно.

PS Или это касается только 3G?

Поделиться сообщением


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

Конечно, видео совершенно не познавательное. Зачем такой большой телевизор, когда хватило бы и ноутбука. И при чем вообще видео, то есть нет смысла тестировать каналы связи просмотром видео, тут тесты более показательные.

 

Слишком большой телевизор - это сильный аргумент. :)

 

Дело в том, что данное видео - это даже не часть испытаний, которые нами проводились. Я увидел, что при переезде с локации LOS на локацию NLOS картинка не рвется? и просто снял видео. Специалисты должны из него сделать следующие выводы: у Камбиума 1) правильно работает адаптация скоростей и 2) есть преобразование малтикаста в юникаст с подтверждениями и повторными передачами в радио (так, что короткого буфера ТВ-приставки хватает для чистой картинки).

 

Любое оборудование заработает в таких условиях, если есть прямая видимость до деревеньки в километре, где БС расположена.

 

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

 

У микротика тут было бы явное преимущество - его можно запитать от прикуривателя, а не таскать инвертор.

 

Конечно, мы все знаем, Микротик настолько крут, что мог бы еще запитать телевизор и ТВ-приставку. :)

 

Наши абоненты питаются от 10...30 В, так что не надо свистеть про явные преимущества.

Поделиться сообщением


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

Подтверждения и повторные передачи - свойство wifi как такового, оно унаследовано всеми решениями на wifi чипах.

Поделиться сообщением


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

Подтверждения и повторные передачи - свойство wifi как такового, оно унаследовано всеми решениями на wifi чипах.

 

Для UDP? Речь шла про малтикаст.

Поделиться сообщением


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

да, и для UDP

Поделиться сообщением


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

да, и для UDP

 

Я извиняюсь, а бродкасты случайно в вашей параллельной вселенной не квитируются?

Поделиться сообщением


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

Я извиняюсь, а бродкасты случайно в вашей параллельной вселенной не квитируются?

Похоже, вы не разбираетесь в вопросе.

Ретрансмит при потере пакета был с начала времен wifi (определялась потеря пакетов по ack-таймауту).

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

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

Поделиться сообщением


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

' timestamp='1494489403' post='1400459']

Я извиняюсь, а бродкасты случайно в вашей параллельной вселенной не квитируются?

Похоже, вы не разбираетесь в вопросе.

Ретрансмит при потере пакета был с начала времен wifi (определялась потеря пакетов по ack-таймауту).

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

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

 

Ага, куда мне. Вы уж просвятите меня тогда, не сочтите за труд. Вот есть, например, у нас 50 клиентов на точке доступа, и она рассылает L2 бродкаст. По вашей логике, все клиенты ей шлют ACK, да? А потом она тем клиентам, которые не ответили юникастом повторяет сообщение? Или опять бродкасты шлёт, пока все ACK не соберет?

Поделиться сообщением


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

По вашей логике, все клиенты ей шлют ACK, да?

А это уж как настроите.

С точки зрения протокола broadcast не является каким-то особенным трафиком (исключительно с точки зрения 802.11 ack на него отсылать не надо, но это настраивается).

Алгоритмов ACK тоже не один и ни два нынче.

 

Хотите проверить? Берете такое древнее говно, как dwl2100 и перешиваете в BB.

Далее крутите hwtxretries и swtxretries в настройках на максимум, и заливаете туда броадкаст.

Там ACK выкручен на очень дальнюю дистаницию (~74км), но он все равно есть.

 

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

Поделиться сообщением


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

' timestamp='1494510466' post='1400552']

По вашей логике, все клиенты ей шлют ACK, да?

А это уж как настроите.

С точки зрения протокола broadcast не является каким-то особенным трафиком (исключительно с точки зрения 802.11 ack на него отсылать не надо, но это настраивается).

Алгоритмов ACK тоже не один и ни два нынче.

 

Хотите проверить? Берете такое древнее говно, как dwl2100 и перешиваете в BB.

Далее крутите hwtxretries и swtxretries в настройках на максимум, и заливаете туда броадкаст.

Там ACK выкручен на очень дальнюю дистаницию (~74км), но он все равно есть.

 

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

 

Насколько я помню(я не настолько старый), то на dwl2100 городили линки точка-точка. В случае точка-точка получатель один, поэтому никаких проблем нет.

Проблемы возникают в многоточке, когда абонентов много.

 

Существует два популярных подхода для посылки броадкаста в многоточке:

 

1. Слать броадкастом на модуляции, которую услышит абонент без переповторов. На всем известном мне оборудовании это делается без квитанции(epmp, canopy, UBNT, mikrotik и тд и тп). Таким же образом это сделано в 802.11.

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

 

С мультикастом немного сложнее получается.

Изменено пользователем m0sia

Поделиться сообщением


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

на dwl2100 городили линки точка-точка

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

Там даже специально ограничение сделали на 6 клиентов в ACL, чтобы держать марку :)

Поделиться сообщением


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

на dwl2100 городили линки точка-точка

и оно работало! без прямой видимости через промзону ставили пролет на секторных антеннах 15 км и даже прокачивали ~2.5 мегабайта в сек. это был где то 2006г. помню еще софтина была для новичков - Acowa AP manager называлась.

Поделиться сообщением


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

' timestamp='1494510466' post='1400552']

По вашей логике, все клиенты ей шлют ACK, да?

А это уж как настроите.

С точки зрения протокола broadcast не является каким-то особенным трафиком (исключительно с точки зрения 802.11 ack на него отсылать не надо, но это настраивается).

Алгоритмов ACK тоже не один и ни два нынче.

 

Хотите проверить? Берете такое древнее говно, как dwl2100 и перешиваете в BB.

Далее крутите hwtxretries и swtxretries в настройках на максимум, и заливаете туда броадкаст.

Там ACK выкручен на очень дальнюю дистаницию (~74км), но он все равно есть.

 

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

 

У меня ощущение, что кто-то тут слегка передергивает. История вопроса:

- У нас есть преобразование мультикаста в юникаст с ACK, что позволяет нормально работать в описанной ситуации.

- Дык у всех есть и вообще это стандартная функция.

- Это нестандартная функция.

- А вот есть dwl2100 и линукс, там можно накрутить.

 

Отлично, хороший вышел спор. Накрутить безусловно можно, но это не стандартная функция стандартов WiFi и большинства оборудования на рынке. В одном секторе mcast-группе могут состоять несколько клиентов, сидящих на различных модуляциях. На какой модуляции прикажете им слать поток? Как добавить квитанции? Вопросов на самом деле больше. Поэтому большинство не заморачивается, малтикаст шлют как бродкаст, на минимальной (или выбранной) модуляции без квитирования. Отсюда быстрое истощение емкости сектора и сбои картинки.

Поделиться сообщением


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

На Wi-Fi мультикаст идет на самой низшей канальной скорости. На мобильнов wimax/LTE это настраивается, то есть можно указать на какой скорости будет вещаться конкретная мультикаст группа, и если абонент не может на этой модуляции работать - он не может получать данные из нее, и емкость сектора не уменьшается.

Поделиться сообщением


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

На Wi-Fi мультикаст идет на самой низшей канальной скорости. На мобильнов wimax/LTE это настраивается, то есть можно указать на какой скорости будет вещаться конкретная мультикаст группа, и если абонент не может на этой модуляции работать - он не может получать данные из нее, и емкость сектора не уменьшается.

 

Емкость сектора всегда уменьшается, потому что в качестве mcast MCS всегда выбирается более низкая модуляция по сравнению с ucast.

Поделиться сообщением


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

- У нас есть преобразование мультикаста в юникаст с ACK, что позволяет нормально работать в описанной ситуации.

да

- Дык у всех есть и вообще это стандартная функция.

да

- Это нестандартная функция.

нет

- А вот есть dwl2100 и линукс, там можно накрутить.

да

 

Надеюсь, вы достаточно стары, чтобы понять шутку :)

Поделиться сообщением


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

' timestamp='1494586425' post=1400791]

Надеюсь, вы достаточно стары, чтобы понять шутку :)

недостаточно

Поделиться сообщением


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

Знатоки, подскажите как прописать маску 0.0.0.0 в дефолтном роуте в режиме маршрутизитора, адрес 0.0.0.0 - дает прописать, а маску 0.0.0.0 - нет.

Мне нужно интернет трафик завернуть на шлюз в локалке.

Изменено пользователем aqwerty

Поделиться сообщением


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

Всем доброго дня. Может не совсем в тему, но не нашел куда написать.

Наблюдаю следующую картину: собран стенд, рабочая сеть->АР epmp1000->CPE epmp1000->MT Hap-> ноут. На АР и СРЕ подняты виланы управления, кроме этого на СРЕ прописан проброс еще нескольких виланов (на АП этого из веб сделать нельзя или не знаю как) для организации работы мониторинга и для тестирования канала. На МТ все виланы растегируются и выводятся на №4 интерфейсе. Что собственно наблюдаю, на тестирование данная связка дает пару минут не более, потом СРЕ перегружается и больше не цепляется к АР. Помогает только перезагрузка по питанию. Настраиваю тот же мост без проброса виланов, исключаю из сети МТ, проверяю подключение к интернету, все работает сколь угодно долго.

Пробую растегировать по очереди вилан доступа к интернету, работает. Растегирую вилан управления и пытаюсь стукнуться на АР, не отвечает или отвечает через раз и получаю перезагруз, если стучаться на другие устройства (UBNT, Ligo) в сети заходит без проблем. Без подключения к эзернет порту СРЕ устройств мост простоял без перегрузки 7ч (ночь). При возникновении проблемной ситуации смотрю на входящем интерфейсе МТ торчем и вижу спонтанное увеличение трафика между устройствами моста до примерно 4мбит/с, 2000ррs и после этого происходит отвал клиента.

Собираю аналогичный мост (хотя аналогичную связку уже проверял на устройствах от лиго) на Ubnt, включаю по схеме приведенной выше, все работает и трафик между устройствами не превышает 100кбит/с, 60-100pps.

Прошивки стоят 3.2, но менял и на 3.4.1, результат тотже. СРЕ и бп менял, дело не в конкретном оборудовании.

Подскажите, что делаю не так?

Цель, подключить на БС epmp1000 клиента, на порту клиента растегировать вилан для доступа в интернет (1хх) и пропустить виланы в тэге(2хх и 1ххх) к устройсвам которые мониторятся и управляются, либо вилан для доступа в интернет другого сегмента сети.

Поделиться сообщением


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

Всем доброго дня. Может не совсем в тему, но не нашел куда написать.

Наблюдаю следующую картину: собран стенд, рабочая сеть->АР epmp1000->CPE epmp1000->MT Hap-> ноут. На АР и СРЕ подняты виланы управления, кроме этого на СРЕ прописан проброс еще нескольких виланов (на АП этого из веб сделать нельзя или не знаю как) для организации работы мониторинга и для тестирования канала. На МТ все виланы растегируются и выводятся на №4 интерфейсе. Что собственно наблюдаю, на тестирование данная связка дает пару минут не более, потом СРЕ перегружается и больше не цепляется к АР. Помогает только перезагрузка по питанию. Настраиваю тот же мост без проброса виланов, исключаю из сети МТ, проверяю подключение к интернету, все работает сколь угодно долго.

Пробую растегировать по очереди вилан доступа к интернету, работает. Растегирую вилан управления и пытаюсь стукнуться на АР, не отвечает или отвечает через раз и получаю перезагруз, если стучаться на другие устройства (UBNT, Ligo) в сети заходит без проблем. Без подключения к эзернет порту СРЕ устройств мост простоял без перегрузки 7ч (ночь). При возникновении проблемной ситуации смотрю на входящем интерфейсе МТ торчем и вижу спонтанное увеличение трафика между устройствами моста до примерно 4мбит/с, 2000ррs и после этого происходит отвал клиента.

Собираю аналогичный мост (хотя аналогичную связку уже проверял на устройствах от лиго) на Ubnt, включаю по схеме приведенной выше, все работает и трафик между устройствами не превышает 100кбит/с, 60-100pps.

Прошивки стоят 3.2, но менял и на 3.4.1, результат тотже. СРЕ и бп менял, дело не в конкретном оборудовании.

Подскажите, что делаю не так?

Цель, подключить на БС epmp1000 клиента, на порту клиента растегировать вилан для доступа в интернет (1хх) и пропустить виланы в тэге(2хх и 1ххх) к устройсвам которые мониторятся и управляются, либо вилан для доступа в интернет другого сегмента сети.

См.здесь

Поделиться сообщением


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

Добрый день

За 2 года в результате эксплуатации у нескольких epmp 1000 (около 20 шт) , отломались, раскрошились и тд. задние крепления к трубостойке. Экспериментальным путем определили , что подходят крепления от force 180/ Где можно приобрести в количестве 20 шт?

Спасибо.

Поделиться сообщением


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

Добрый день

За 2 года в результате эксплуатации у нескольких epmp 1000 (около 20 шт) , отломались, раскрошились и тд. задние крепления к трубостойке. Экспериментальным путем определили , что подходят крепления от force 180/ Где можно приобрести в количестве 20 шт?

Спасибо.

Обращайтесь к своему продавцу, у него должно быть в наличии. Камбиум недавно делал отгрузку этих креплений своим партнерам ( возможно не всем , а тем, кто просил) для решения этого вопроса. Если у вашего продавца нет, то скорее всего есть у его дистрибутора.

Поделиться сообщением


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