Подскажите как более менее точно получать UTC время в долях секунды в С.

https://stackoverflow.com/questions/32000328/libgps-c-code-example/32000487#3...

Хммм, это если есть GPS приемник ... А без GPS?

Поставь и настрой ntpd. А дальше элементарно: gettimeofday и преобразования.

Подскажите как более менее точно получать UTC время в долях секунды в С.

Ещё менее точно?
Используй генератор случайных чисел.

Можно за $1500 купить чип с атомными часами: https://www.popsci.com/technology/article/2011-05/smallest-atomic-clock-ever-...

имелось ввиду точнее чем gettimeofday() в стандартно сконфигуренной системе.

более‐менее
более или менее

Забавная ошибка.

имелось ввиду точнее чем gettimeofday() в стандартно сконфигуренной системе

clock_gettime()

Не понял намека. С моей колокольни - тоже самое, но в профиль.

На таких интервалах точно может быть только относительное время (спустя 10 микросекунд, например).

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

А ультрамегасуперточное время тебе никто не покажет.

Этого не требуется. Точнее чем gettimeofday() в стандартно сконфигуренной системе.

gettimeofday() выдаёт время с точностью до микросекунд, clock_gettime() - до наносекунд. Так что точнее в стандартно сконфигуренной системе. :)

А какова точность часиков в этой твоей «стандартно сконфигуренной системе»? И да, даже gettimeofday оперирует структурой, в которой есть обычный unixtimestamp и некие микросекунды, скорее всего вычисляемые делением тиков на частоту или как-то так.

Точнее чем gettimeofday() в стандартно сконфигуренной системе

clock_gettime(CLOCK_REALTIME)?

Эххх ... Тут подлянка в том что тут физически милисекундам неоткудова взятся, неговоря уже о микро и нано. Можешь рассматривать рассматривать всю дробную часть как тупой счетчик никак не коррелирующийся с UTC.

Почти всегда это одно и тоже.

Тут проблема не в самой точности а в корреляции этих часиков с UTC. На всех обычных стандартных системах - она никакая. Что надо сделать чтобы хоть чтото гарантировалось я не знаю и собственно пытаюсь выяснить.

Ну раз так...

struct timex timex = {
	.modes = 0,
};
int status = adjtimex(&timex);
assert(status != TIME_ERROR);

И дальше делаешь clock_gettime(CLOCK_REALTIME). :)

Иными словами: если точность системных энергонезависимых часов тебя не устраивает, то твой вопрос — не «как получить точное время из C», а «как вообще получить на машину точное время». Например, по NTP. И дальше получать его из C стандартными средствами.

Почти всегда это одно и тоже.

Порядка 100 нс на ноуте между двумя последовательными вызовами. Это в 10 раз лучше, чем в принципе gettimeofday() с микросекундами в принципе может дать.

У тебя, наверное, просто таймера в системе точнее микросекунд нет.

то твой вопрос — не «как получить точное время из C», а «как вообще получить на машину точное время»

200%.

Например, по NTP.

Вам известны другие варианты? Выше предлагали по GPS.

И дальше получать его из C стандартными средствами.

Ты намекаешь на libntp?

У тебя, наверное, просто таймера в системе точнее микросекунд нет.

я имел ввиду немного другое: эти два вызова обращаются к одному и томуже физическому таймеру довольно плохо коррелирующемуся с UTC.

Вам известны другие варианты?

kernel PPS discipline, PTP... Ну то есть либо личные атомные часы, либо GPS, либо NTP. Ещё есть периодические радиосигналы, но у них точность низкая.

Ты намекаешь на libntp?

Я намекаю на то, что если в системных часах не хватает точности, то её нужно там сделать (любым доступным способом, откуда я знаю, что у тебя за условия). Я просто не понимаю вопроса: ты хочешь услышать какой-нибудь магический способ получить точное время на изолированном компьютере без аппаратных часов соответствующей точности?

ты хочешь услышать какой-нибудь магический способ получить точное время на изолированном компьютере без аппаратных часов соответствующей точности?

не совсем. Я хочу быть уверенным что полученное время гарантированно не отличается от UTC более чем на некоторую небольшую, наперед заданную величину, например 100 мс. gettimeofday() и аналогичное вполне может вернуть 1970 год или что-то подобное.

Ты нихера не понял из вышеописанного. 1. Та гоняешь ntpd на машине с часами и получаешь точное время. 2. Используешь стандартное API для оного (gettimeofday())

Если ты хочешь гарантий, тебе их никто не даст. Читай протоколы, думай что тебе нужно.

Для этого достаточно проверить, что ntpd вышел на стабильный режим. Атомные часы тоже могут сломаться вообще-то.

Это я уже предложил. Почему-то ТСа такой ответ не устроил.

Для этого достаточно проверить, что ntpd вышел на стабильный режим.

Хм ... Полистаю доки

Атомные часы тоже могут сломаться вообще-то.

кстати, вам известны преценденты?

Мой мозг был неготов :-) на сейчас ситуация более-менее прояснилась

Elyas. Кстати, а случайно не в курсе как именно определить что синхронизация была потеряна? Ну там канал к вышестоящему NTP серверу лёг ... По документации я понял что это возможно не непонял как именно.

Попробуй через тот же adjtimex()? Ну то есть я не знаю, выставляет ли ntpd флаг STA_UNSYNC, если связь легла после успешной синхронизации, но по здравому смыслу — должен выставлять, как минимум когда определит, что предсказанная ошибка вышла за пределы допустимого. Думаю, логично просто проверять возвращаемое значение adjtimex() в режиме чтения (timex.modes == 0).

Ты ассерты и в продакшен будешь писать? Этот фанбойчик далеко пойдет.

Нормальные чуваки в «продакшн» ничего не пишут!

Это пример. Его задача — быть понятным, а не корректным.

Ты только преподавать не иди.