Странный приём по UDP

[ladik]

Всем здрасте! Стоит задача синхронизации времени на cRIO c GPS или локальным временем сервера. В приоритете GPS. Реализую задачу с помощью конечного автомата. Время с GPS приёмника получаем по COM-порту. Пока эта часть не закончена. Чтобы была точная синхронизация нужно принимать "свежее сообщение" после PPS импульса. В случае отсутствия GPS, синхронизация идёт по UDP. Читается время из порта, которое сервер туда отправляет. На картинке можно увидеть 2 разные реализации. Разница в том, что во 2м случае порт открывается единожды, а в 1м на каждой итерации. Так вот, когда порт открыт 1 раз, первая синхронизация проходит нормально, а последующие странно. С UDP приходят неактуальные "старые" данные о времени. Если внести открытие порта в цикл, то всё работает отлично. В принципе, задача вроде как решена, но мне не даёт покоя непонимание почему именно так всё работает? Может у UDP порта есть приёмный буфер? Тогда всё более менее ясно. При закрытии он очищается, и мы видим последнее принятое сообщение.

[Borjomy_1]

По поводу самого UDP не скажу, а вот по диаграмме есть замечание: у вас слева внизу сброс индикаторов. Вы в курсе, что в таком виде сброс происходит когда угодно, а не перед выполнением цикла? Для нормальной последовательности надо хотя-бы выходы ошибок с них завести на цикл. Их можно никуда не подключать больше, просто подцепить к левой части рамки цикла.

[ladik]

Borjomy_1, Спасибо за замечание! Да, я в курсе! Для отладки сделал просто, чтоб сбрасывало "где-то на старте". По хорошему их в разрыв кластера ошибок при инициализации надо бы. Честно скажу пока этому не уделял внимания, ровно как и обработке ошибок.

[Borjomy_1]

Попробуйте явно выставить размер пакета.

[ladik]

Borjomy_1, если я правильно понял, что Вы имеете в виду, то в функции UDP Read нужно указать значение поля max size. Это я пробовал, не помогло, к сожалению.

[Kosist]

ladik, Вы отсылаете данные каждые 50 мс, а при считывании выплывает задержка в 250 мс (после синхронизации времени, в Вашей программе есть переход на стейт blank). А в UDP есть буфер, в который за это время задержки пишутся данные. И при следующем чтении программа получает не актуальную информацию, а время из буфера.
Нужно, значит, как-то очищать/уменьшать буфер.

[Borjomy_1]

Либо посылать реже. Зачем 50мс? Настолько неточные внутренние часы? Да сетевые задержки на порядки больше.

[ladik]

Kosist, примерно это я и предполагал. Остановился на втором решении, с постоянным открытием/закрытием порта на приёмном устройстве. Работает нормально. Пока так и оставлю.

Borjomy_1, данные шлются в порт постоянно. Чем точнее синхронизация, тем лучше для системы в целом. А по поводу задержек на порядок. Действительно задержки на передачу будут в пол секунды? Я почему-то считал, что поменьше.

[Borjomy_1]

Предположим, у вас часы расходятся за 50мс на 1 мкс. Возможно? Почему-бы и нет, это соответствует ~2 секундам в сутки.
Вопрос первый: таймстамп с каким реальным дискретом?
Вопрос второй: вы оценивали транспортные задержки между получением таймстампа и приемом контроллером, и их волатильность? Они наверняка будут значительно больше этой самой 1мкс.

[ladik]

И тут я завис В реальной жизни синхронизация будет проходить раз в несколько часов/раз в сутки. Дело ещё и в том, что на всех контроллерах время должно быть как можно более одинаковым. Вплоть да сотен миллисекунд.

[Kosist]

И тут я завис В реальной жизни синхронизация будет проходить раз в несколько часов/раз в сутки. Дело ещё и в том, что на всех контроллерах время должно быть как можно более одинаковым. Вплоть да сотен миллисекунд.

Так тогда проблем вообще нет. Отсылайте время для синхронизации раз в час/сутки, и все - скажем, несколько значений с некоторым интервалом на случай, если данные потеряются. Можно тогда feedback прикрутить от виайки-приемника, и когда будет отослано подверждения приема и синхронизации, перестать слать можно время для синхронизации.
Данные не потеряете, и будете уверены в синхронизации.

[ladik]

Kosist, спасибо за совет! Буду думать как лучше реализовать.