Здравствуйте.

Есть удаленный компьютер, который регулярно шлет свои таймстемпы (время). Хотелось бы на локальной машине контролировать дрейф часов.
Как это лучше организовать? При этом удаленная машина синхронизирована по ntp, а локальная не факт. Вижу 2 сценария.

1)Если обе машины -- локальная и удаленная -- синхронизированы по ntp, то по идее это несложно -- смотрю на разность времени, должна
быть в каких-то границах. Но при этом если начнется расхождение, как понять, кто косячит? Может, например, проблемы с синхронизацией
с ntp сервером и т.п.

2)Если только удаленная машина по ntp синхронизирована, тут по идее вообще решений не видно, т.к. если дрейфует локальная машина,
то сказать ничего нельзя. Или можно?

В общем, сталкивался ли кто-нибудь с подобными задачами, т.е. контролировать время удаленной машины.

Заранее благодарю.

Здравствуйте, Sharov, Вы писали:

S>В общем, сталкивался ли кто-нибудь с подобными задачами, т.е. контролировать время удаленной машины.
Не очень понял зачем вообще некая локальная машина. Запускаем ntp и смотрим его логи — он и показывает статус синхронизации (по алгоритмам, на которых не одну докторскую защитили). Т.е. тебе нужен health-check ntp-клиента на целевой машине.

Здравствуйте, Sharov,

Не уверен, что все правильно понял, но, 2 независимых узла -> распределенная система -> время синхронизировать невозможно -> нужно вводить частичную упорядоченность событий, реализовывать какой-то свой аналог часов Лэмпорта. Конкретнее сказать сложно, потому что не очень понятно, что такое "контролировать дрейф часов".)

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Sharov, Вы писали:

S>>В общем, сталкивался ли кто-нибудь с подобными задачами, т.е. контролировать время удаленной машины.
·>Не очень понял зачем вообще некая локальная машина. Запускаем ntp и смотрим его логи — он и показывает статус синхронизации (по алгоритмам, на которых не одну докторскую защитили). Т.е. тебе нужен health-check ntp-клиента на целевой машине.

Задача на локальной машине понять, что с часами удаленной машины все нормально. При этом локальная получает от удаленной
только таймстемпы. В данных рамках как-то можно эту задачу решить? Ну т.е. |DataTime.Now — receivedTs| должна быть в определенных
границах, при условии что на локальной машине нет проблем с часами. По идее, если оба синхронизированы по ntp, то этого более чем
достаточно.

Здравствуйте, jahr, Вы писали:

J>Здравствуйте, Sharov,
J>Не уверен, что все правильно понял, но, 2 независимых узла -> распределенная система -> время синхронизировать невозможно -> нужно вводить частичную упорядоченность событий, реализовывать какой-то свой аналог часов Лэмпорта. Конкретнее сказать сложно, потому что не очень понятно, что такое "контролировать дрейф часов".)

Нет, тут мне важно знать именно точное физическое время, время кадра. Просто необходимо понять, а можно положиться на время камеры (удаленной машины)
или это фигня.

Здравствуйте, Sharov, Вы писали:

S>>>В общем, сталкивался ли кто-нибудь с подобными задачами, т.е. контролировать время удаленной машины.
S>·>Не очень понял зачем вообще некая локальная машина. Запускаем ntp и смотрим его логи — он и показывает статус синхронизации (по алгоритмам, на которых не одну докторскую защитили). Т.е. тебе нужен health-check ntp-клиента на целевой машине.
S>Задача на локальной машине понять, что с часами удаленной машины все нормально. При этом локальная получает от удаленной
S>только таймстемпы. В данных рамках как-то можно эту задачу решить? Ну т.е. |DataTime.Now — receivedTs| должна быть в определенных
S>границах, при условии что на локальной машине нет проблем с часами. По идее, если оба синхронизированы по ntp, то этого более чем
S>достаточно.
Так тоже всё просто "условии что на локальной машине нет проблем с часами." — это легко проверяется по статусу ntp-клиента локальной машины. Т.е. локальная машина бьёт тревогу если ntp-клиент сломался или если |DataTime.Now — receivedTs| разъехался.

To obtain a brief status report from ntpd, issue the following command:

~]$ ntpstat
unsynchronised
time server re-starting
polling server every 64 s
...
~]$ ntpstat
synchronised to NTP server (10.5.26.10) at stratum 2
time correct to within 52 ms
polling server every 1024 s

Ну когда тебе приходит время удаленной машины, сравнивай со своим текущим и получишь величину дрейфа. Вроде очевидно или я что-то не понял?

Здравствуйте, Sharov, Вы писали:

S>Нет, тут мне важно знать именно точное физическое время, время кадра. Просто необходимо понять, а можно положиться на время камеры (удаленной машины)
S>или это фигня.

Тогда, наверное, правильно сравнивать полученное время не с локальным, а со временем, полученным от NTP сервера (и локальное тоже с ним сравнивать, если нужно). Можно посмотреть как это сделано в ntpclient http://doolittle.icarus.com/ntpclient/

Здравствуйте, Sharov, Вы писали:

S>Нет, тут мне важно знать именно точное физическое время, время кадра. Просто необходимо понять, а можно положиться на время камеры (удаленной машины)
S>или это фигня.

В такой постановке задача решается так: можно положиться, а можно не положиться. Одному можно, другому — нет. Субъективно. Требуется ввести некоторую погрешность хотя бы, что бы попытаться понять, внутри погрешности время кадра или нет.
И только тогда начнется самое интересное, т.к. время доставки ответа с сервера синхронизации — величина непостоянная и это время само может плавать. И то, что время в допустимой погрешности, мы можем сказать лишь тогда, когда все хорошо. А когда что-то не хорошо, причина не ясна. Известно, что пол часа назад время было в погрешности. А что с этим дальше делать —

Здравствуйте, Sharov, Вы писали:

S>Есть удаленный компьютер, который регулярно шлет свои таймстемпы (время). Хотелось бы на локальной машине контролировать дрейф часов.
S>Как это лучше организовать? При этом удаленная машина синхронизирована по ntp, а локальная не факт. Вижу 2 сценария.

Как-то противоречиво звучит. Вроде как дрейфуют часы локальной машины, а контролировать хочется дрейф удаленной.

S>1)Если обе машины -- локальная и удаленная -- синхронизированы по ntp, то по идее это несложно -- смотрю на разность времени, должна
S>быть в каких-то границах. Но при этом если начнется расхождение, как понять, кто косячит? Может, например, проблемы с синхронизацией
S>с ntp сервером и т.п.

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

S>2)Если только удаленная машина по ntp синхронизирована, тут по идее вообще решений не видно, т.к. если дрейфует локальная машина,
S>то сказать ничего нельзя. Или можно?

А почему нельзя засинхронизировать локальную машину?

Здравствуйте, Pzz, Вы писали:

S>>2)Если только удаленная машина по ntp синхронизирована, тут по идее вообще решений не видно, т.к. если дрейфует локальная машина,
S>>то сказать ничего нельзя. Или можно?
Pzz>А почему нельзя засинхронизировать локальную машину?

Похоже, я условие переврал -- ntp сервис будет на локальной машине, и надо оценивать как синхронизируется удаленная машина.
Может там что-то пошло не так и синхронизация по ntp отвалилась, при этом удаленная машиня нам регулярно шлет таймстемпы(т.е.
физическое время кадра, например).

Здравствуйте, Sharov, Вы писали:

S>Похоже, я условие переврал -- ntp сервис будет на локальной машине, и надо оценивать как синхронизируется удаленная машина.
S>Может там что-то пошло не так и синхронизация по ntp отвалилась, при этом удаленная машиня нам регулярно шлет таймстемпы(т.е.
S>физическое время кадра, например).

Ну можно, например, провести (периодически проводить) синхронизацию с ней. NTP, кроме подведения часов, дает еще довольно много информации о том, как вообще прошла синхронизяция — надо посмотреть поподробнее в описании протокола. Эта информация позволяет судить о том, что происходит со временем на удаленной машине.