Как то не так.
Синхронизация времени по 103 или иному протоколу подразумевается в широковещательном формате, то есть посылка от источника принимается всеми устройствами одновременно, а не последовательно. Для этого имеется специальный формат команды синхронизации, типа "Внимание всем, следующей командой будет метка времени!". Вопрос в другом, как точно сможет выдать контроллер эту метку, какому моменту времени соответствует содержимое метки, учитывается или нет транспортная скорость. Суть в том, что действительно, не зная условий формирования метки времени невозможно ее правильно использовать. Можно заставить контроллер корректировать миллисекунды в посылке в соответствии со своими задержками в порту связи, а можно это сделать и в приемнике. А можно ни как не корректировать, подразумевая, что в пределах 0,5 сек метка времени будет принята в любом случае, а начало секунды считать от прихода PPS, то есть обнулять счетчик миллисекунд.
Дальше интересней. А кому нужна микросекундная точность синхронизации календарных часов. По всем СТО внутренние часы должны тикать с разрешением 1 мс. Можно, конечно, задействовать прецизионные протоколы синхронизации и получить наносекунды, но как их использовать? Я говорю именно о часах реального времени, календарных, а не о синхронизации в шине процессов, где требуется 1 мкс.
Собственно по этому, при правильной реализации синхронизации только по 103 или проприетарному протоколу связи, достижима точность синхронизации ведомых часов 1 мс с часами источника. Использование PPS исключает зависимость от программной реализации синхронизации и позволяет в любом случае получить точность 1 мс, главное, что бы источник меток (тот же контроллер) был синхронизирован с тем же сервером времени, который раздает PPS.