В недавнем обновлении telegram появилась возможность добавить к каналу чат для обсуждения. Таким образом под постами в канале появляется кнопка "обсудить". Собственно, это избавляет от необходимости форвардить посты из канала в чат.

Нас просто так не ломануть :)

Коллеги, тут аж в нескольких проектах столкнулись с тем, что часы #PTP, не будучи переведенными принудительно в slave-only, перехватывали на себя синхронизацию, если мастер отваливался. Обычно в проектах такой баг устраняют при первом же появлении (то есть на всех часах, кроме GM ставят slave-only). А надо ли его устранять? Может лучше оставлять эту фичу включённой и не ставить прорву дублированных серверов времени?

Конечно оставляйте. Сервер времени не нужен. А насколько в терминалах часы говно время покажет

Часы ptp - это вторичные сервера времени или часы устройств?

Такой косяк может возникнуть только в режиме  E2E. А это идёт в разрез с  power profile.

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

Для того чтобы этот механизм не выбрал левый сервер времени имеется два поля приоритета

Как в Rstp bridge priority

Все верно.

Тоже не понимаю при чём тут E2E. Тут речь про то, шлют ли часы Announce или не шлют никогда

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

Ну если все на одни, то может и нормально. Но ФСК требования на ПАСы выдал такие, что они могут почти сервером времени быть.

Понятно что это не нормальная. Конечное устройство в принципе в такой роли работать не должно и не проектируется для этого. Конечно если в нем не установлен термостабильный рубидивый резонатор :).
В таком случае такому источнику СЕВ можно тоже доверять ;)

У ФСК точность хода сервера времени и ПАС 0.01ппм, если мне память не врёт.