Микротик радиомост, потеря кадров, клиенты только ip камеры?
Добрый вечер.
Есть проблема с передачей потока с ip камер.
Мост на RBSXTG-2HnD (AP) и SXTsq Lite2 (клиенты, 2 шт.)
Клиенты только ip камеры, других устройств нет, трафик только на отдачу.
С одной точки 6 мбит/с, с другой около 20 мбит/с.
Расстояние от AP 300 м.
Проблема в том, что в основном потоке доходят не все пакеты (потери кадров). Как я понимаю это из-за битрейта (на доп. потоке он довольно низкий и с ним проблем нет). В основном потоке битрейт с камеры 4-6 мбит/с.
Протокол nv2 (на 802.11 та же проблема)
С зоной френеля всё ок, препятствий нет. объект в поле. Из радио соседей, есть линк от провайдера, каналы с ним разные.
Собственно как избавиться от потери кадров? Как правильно на микроте настроить приоритет на отдачу трафика (на клиентах rx нет, только tx)? И имеет ли смысл менять дефолтные значения в Queues для wireless интерфейса?
Может есть какая-нибудь статья или обсуждение на форуме по настройке моста именно с клиентами в виде ip камер?
Если нужно конфиги, скрины всё пришлю, сейчас доступа к точкам нет.
PS: отключение AMSDU Limit или AMSDU Threshold может "починить" передачу данных. Выставил оба этих параметра в 0 и стало намного стабильнее. По умолчанию было 8192, да во всех мануалах что мне попадались советуют не трогать эти параметры.
Нужна схема расположения ap с расстоянием до каждой клиентской и угол между ними. Оборудование нормально заведено друг на друга? Какой ccq на каждом устройстве? Зачем убили amsdu (вы читали описание этой настройки?)?
А в целом скорее всего камеры у вас работают на UDP и перевод на tcp окажется тем самым волшебным костылем, который вы ищите, вместо пошаговой настройки мостов по мануалу, которых сотни.
Камеры подключены по tcp, ccq на скринах. Расстояние клиентов до AP около 300 м. AP с одним клиентом направлены друг на друга, второй клиент заведён в сторону градусов 20 от AP.
Зачем убил amsdu? Как бы перебрал уже много вариантов/комбинаций параметров и решил, а почему бы не убить amsdu. Как я понял amsdu помогает в передачи мелких пакетов, а здесь таких нет.
И после того как убил amsdu основной поток с камер стал быстрее "грузиться", когда в режиме просмотра переходишь с доп. потока на основной, то время этого перехода сократилось (время буферизации).
Камеры дахуа, если подключены по родному протоколу DH2 на NVR или фирменный клиент, работают в первую голову по UDP, или если видят по пути шлюз то по RTP. А иногда сразу по RTP -- просто версия прошивки должна быть удачная. Такое да, потери пакетов по воздуху дает, UDP пакеты не доходят, RTP пакеты протухают. Посмотрите у себя в регистраторе, не помню в точности имя настройки, она глобальная, связана с "streaming metod", TCP ваш выбор. Еще посмотрите настройки кодирования видео на камере, или киньте сюда -- я завтра посмотрю. Я предпочитаю для дахуа h265, VBR, max bitrate 4096 (1080) 6144(5-8Mpix), 20 FPS, I-frame int 40, реальный поток при этом достигает 4 Мбит только при очень интенсивной движухе в кадре при приличной разборчивости лиц и номеров. Вообще на линке 6Мбит потери ощутимо сильнее чем на 20, или не видно глазом разницы?
mordo445,
камеры подключены по порту 37777, а это как я понимаю tcp порт, порт для udp 37778.
На глаз разницы между 6 мбит и 20 мбит не вижу, и там и там потери.
Максим, Ух как интересно у вас на стороне 192.168.1.80, сколько сессий сразу. И все какие то дохленькие, по 200 кБ. Как правило 1 видеопоток -- одна сессия. У вас там на бэке 1 NVR и всё? Я тут в командировке, оперативно не получилось, извините
Средний
Сложный
Простой
