+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Поддержка IEEE1588 PTPv2 для CRS317

Поддержка IEEE1588 PTPv2 для CRS317, RouterOS

uldis

Guest

21.11.2019 09:31:00

Мы планируем ввести функцию IEEE1588 PTPv2 для некоторых переключателей серии CRS317. В данный момент мы планируем добавить поддержку для граничных часов IEEE1588 PTPv2, которые могут работать через транспортный уровень layer2/udp4, а также возможность выбора режима задержки end-to-end/peer-to-peer. Поддержка 802.1AS (gPTP) также будет добавлена. Обратите внимание, что часы не синхронизированы с системными часами. Можете оставить нам отзывы, если хотите использовать эту функцию в наших переключателях CRS? Какие дополнительные опции вы хотели бы, чтобы мы добавили для этой функции?

tmichaud Guest	#2 0 17.02.2020 14:57:00 Есть ли какие-то новости о прогрессе по поддержке IEEE1588 PTPv2?

ste

Guest

10.03.2020 08:35:00

Сначала сделайте этот свитч надежным. Подключение 10G и 1G по-прежнему вызывает проблемы. У нас пропадает пакет и возникают перебои с туннелями VPLS. Я даже не вижу, идет ли согласование управления потоком? Как вы тестируете этот свитч без этой информации? Мы рассматриваем возможность удаления всех наших CRS317 в данный момент.

tmichaud Guest	#4 0 07.04.2020 17:26:00 Есть ли обновления по поддержке IEEE1588v2?

daemontux Guest	#5 0 25.12.2020 04:15:00 Скорее всего, это невозможно сделать программно. Нужен специализированный ASIC и кварцевый генератор.

pjinkcc

Guest

07.07.2022 10:05:00

Согласно: https://help.mikrotik.com/docs/display/ROS/Precision+Time+Protocol PTPv2 поддерживается на: CRS326-24G-2S+ — поддерживается только на портах Gigabit Ethernet CRS328-24P-4S+ — поддерживается только на портах Gigabit Ethernet CRS317-1G-16S+ — поддерживается на всех портах CRS326-24S+2Q+ — поддерживается на интерфейсах SFP+ и QSFP+ CRS312-4C+8XG — поддерживается на всех портах CRS318-16P-2S+ — поддерживается только на портах Gigabit Ethernet Я хочу получить один из этих коммутаторов, чтобы протестировать его с моим аудио интерфейсом MOTU 828es AVB и другим AVB аудиоустройством для расширения аудио ввода/вывода с моего локального студийного/офисного коммутатора. Но мне интересно… если CRS326 совместим, будет ли также совместим CSS326 (только версия коммутатора)?

rounin

Guest

16.07.2022 10:42:00

(запрос на функцию) Похоже, что коммутаторы в RB5009 (88E6393X) и CCR2116 (98DX3255) поддерживают PTP 1588v2 — я был бы заинтересован в использовании их в качестве прозрачного тактового генератора. Они достаточно похожи на коммутаторы в CRS317, чтобы их можно было активировать? У меня есть GPS/OCXO PTP главного генератора, и в настоящее время я использую IGS-6325-8UP2S2X в качестве прозрачного тактового генератора в проекте синхронизации видеосигналов. Мне нужно больше портов

. Если коммутатор CCR2116 или rb5009 тоже сможет участвовать в распределении 1588v2, это очень помогло бы.

chechito

Guest

16.07.2022 13:55:00

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

rounin

Guest

16.07.2022 18:00:00

учитывайте, что коммутаторы CSS практически не требуют процессорных ресурсов и памяти для работы дополнительных функций. Для пограничных часов это в основном аппаратная функция. Чипы коммутаторов корректируют метку времени 1588v2 по мере прохождения через коммутатор (или когда застревает в очереди выхода). На самом деле, почти никакое программное обеспечение не работает, кроме активации аппаратного обеспечения.

pjinkcc

Guest

#10

20.07.2022 00:17:00

Все в порядке, это будет подключено к моему основному маршрутизатору Mikrotik и не потребуется никакой маршрутизации, фильтрации и т.д. Просто базовое коммутирование в офисе. Так что это, похоже, идеально. Главное, чтобы он мог переключать аудиопакеты AVB. Я хочу протестировать это скоро.

mjezierski

Guest

#11

16.09.2022 14:06:00

Все ли коммутаторы от конца до конца должны поддерживать IEEE1588? Мне нужно, чтобы возможно поддерживать IEEE1588 на краю сети. У меня есть уже существующие коммутаторы CRS317-1G-16S+ (в данный момент работают на SwOS, но могут перейти на ROS, если потребуется) в ядре с устройством GPS другого производителя, которое может работать как GM, но также я приобрёл CRS328-4C-20S-4S+RM в качестве распределительного коммутатора на периметр. Я рассматриваю возможность использования NetPower 16 (CRS318-2S+16P) на краю сети, чтобы обеспечить последний километраж до конечных устройств. Таким образом, путь в сети будет GM ↔ CRS317 ↔ CRS328 ↔ NetPower 16P ↔ Конечное устройство. На данный момент через эту сеть не передается видео, только аудио.

emunt6 Guest	#12 0 31.12.2022 00:04:00 Это возможно с дополнительным модулем SFP: OSA 5401 - приемник GNSS в малом форм-факторе (SFP) и мастер-годинник PTP.

mkx

Guest

#13

08.01.2023 12:10:00

С технической точки зрения: нет. С точки зрения точности: да. Основная цель использования IEEE1588 (в отличие от обычного NTP) заключается в том, чтобы предоставить OC точную информацию о задержке между GM и самим собой. Задержка в основном обусловлена двумя причинами: физическая задержка канала. Эта задержка на большинстве каналов постоянна и является суммой задержки на физическом порту (преобразование параллельного сигнала в последовательный и др.) и задержки на самом канале (из-за конечной скорости сигнала). Эта задержка является свойством конфигурации каждого канала и может различаться в каждом направлении (например, большая задержка при преобразовании параллельного сигнала в последовательный в более медленном направлении на линиях с асимметричными скоростями). задержка в активном оборудовании. Эта задержка может сильно варьироваться в зависимости от того, как устройство обрабатывает пакеты (например, очереди), а поддержка IEEE1588 на этих устройствах улучшает точность, поскольку задержка каждого отдельного временного пакета может быть точно определена (и добавлена к уже имеющейся информации о задержке) на выходе. Если в пути между GM и OC есть оборудование, не поддерживающее IEEE1588, отсутствие точных измерений задержки снизит точность полученных меток времени. Если устройство, не поддерживающее IEEE1588, не испытывает никаких задержек, так что задержка пакетов, проходящих от GM к OC, довольно постоянна, тогда возможно добавить эту задержку к каналу между смежными устройствами IEEE1588, и тогда точность будет в основном хорошей (хуже, чем если бы все устройства были IEEE1588, но не сильно). С другой стороны, если устройство, не поддерживающее IEEE1588, иногда испытывает задержки, точность временной информации падает до минимума (и становится не намного лучше, чем у обычного NTP).

brotherdust

Guest

#14

17.02.2023 22:11:00

Эта функция была бы полезной! Могу ли я сделать несколько дополнительных предложений, чтобы сделать PTP еще более удобным? PPS или вход 10 МГц для GM. Я хотел бы подключить свой GPS напрямую к 317, если собираюсь использовать его в качестве GM. В противном случае, рассмотрите возможность создания отдельного устройства для работы в качестве GM с использованием Open Time Server в качестве эталона. Включите транспорт IPv6.

brotherdust Guest	#15 0 17.02.2023 22:12:00 О, вау! Это действительно классное устройство! Спасибо!

dgel27

Guest

#16

21.02.2023 20:52:00

Вы можете попробовать MiCLK от RAD. Это практически то же самое устройство, что и OSA5401, с веб-интерфейсом и примерно на 30% дешевле. Но есть один нюанс: мы будем использовать ADVA — MiCLK не начнет работу как GM, пока он не будет заблокирован. ADVA может работать на своих часах Stratum 3. В конце концов, я настроил CRS326-24S+2Q+ как fronthaul 5G SA базовую станцию с поддержкой PTP. 4 RU работают в MIMO 4x2 (4T2R), синхронизированные с ADVA OSA5401, и все работает отлично. Настройка свича не такая ясная, как у других свитчей, но это возможно. Есть некоторые проблемы с реализацией PTP: пакеты L2 GM не изолированы в мосте. Так что если адрес PTP назначения является переадресуемым MAC (01-1B-19-00-00-00), то все PTP пакеты распространяются на все порты моста, а устройства-слуги также видят пакеты GM и могут выбрать GM. Если я меняю адрес назначения PTP на непереадресуемый MAC (01-80-C2-00-00-0E), то анонсирующие и синхронизирующие пакеты не переадресовываются, но свитч отправляет delay_request на (01-1B-19-00-00-00), и ADVA также отвечает на (01-1B-19-00-00-00), поэтому эти пакеты тоже распространяются на все порты. Нет возможности добавить VLAN к трафику PTP, и правила свитча также для меня не работают. Единственный способ, который я нашел — создать отдельный мост для GM. Порты PTP слуг также не изолированы, поэтому весь мультикастный PTP трафик проходит через все PTP порты. Это меньшая проблема, но обычно BC свитчи изолируют весь PTP трафик по своим портам. В реализации PTP есть одна ошибка: когда GM уже заблокирован, свитч вдруг меняет TOD на огромное значение (часы, месяцы, годы), свитч никогда не приходит в синхронизированное состояние. Это может произойти, когда сигнал GPS GM потерян, GM теряет питание и т.д. Если Mikrotik использует ptp4l, лучше добавить step_threshold 0.002 в настройки. Я действительно жду 100G свитчей Mikrotik с поддержкой PTP. 10G уже выходит из сегмента связи. Может, кто-то может помочь мне с настройкой маршрутизации к PTP мосту? GM имеет статический IP из той же управляющей сети, и мне нужно получить доступ к SSH, TELNET, логам и NTP GM. Спасибо!

dalun Guest	#17 0 27.02.2023 17:12:00 Кто-нибудь тестировал, что коммутатор MikroTik полностью поддерживает AVB?

hknet Guest	#18 0 23.02.2020 08:19:00 С точки зрения поставщика - это приятно, но честно говоря, я бы предпочел, чтобы на оборудовании crs317 реализовали другие функции чипа.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры