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

Тема мутная. Это видно как M$ ретуширует ее десятилетиями ужЕ.

Реализовано два таймера:
1. QueryPerformanceCounter
2. GetSystemTimeAsFileTime

Первый - для собственно взятия отсчетов времени. Второй - для привязки первого к системному времени. Как без использования внешнего эталона первого стратума (да любого!) обеспечить достоверность первого таймера? Через периодически вносимую в БД поправку на ветер.

Нужны именно наносеки. Если бы микро, хотя бы, то насрать - усушка, утруска...

Кто дрифтит относительно кого?! Чей кварц надежнее? Как это попытаться хотя бы субъективно оценить - кто плывет относительно кого? Дрифт в районе 3 сек в сутки и сильно зависит от железа.

Даже если есть способ ответить на вопрос выше - Чей кварц надежнее? - то, как это привязать к конкретному (произвольному) железу?

Задача усложняется тем, что единственная пауза в течение суток лишь в районе 21-23. Т.е. переход через нули (читай - через дату) неизбежен.

Задача упрощается тем, что на пояса можно забить - все в классическом GMT/UTC.

Я понимэ, что вопрос этот более в сторону геймерских форумов, но туда без знания Си и Асм лучше не входи...

Но и там в первую очередь наклонят в сторону kernel-mode API KeQueryPerformanceCounter, или, что еще хлеще, в сторону RDTSC или RDTSCP...

--------------------------

Тут многие в бой рвутся с невостребованным своим знанием...
зей ар велкам ту :)
.
.

Парни, спасибо.

Модеры - зря потерли первый ответ. Он, хоть и был чутка с недопонианиме проблемы, но характеризовал ее этим. Дело не в сутгочном дрифте, а в моментном. У второго таймера 15 мск на оюычной машине. Брать отсчеты в этом его промежутке смысла нет. А вот привязывая эти 15-мск зазоры к тактам кварца, отдаваемым QueryPerformanceCounter получаем этот самый дрифт, который, понимания для, легче первести в суточную величину. У меня есть графики этого дрифта, но рука правая уже не моя. Потом, половчее бцдц, покажу.

Кто мне отвечал в потертом:
ЩСА5 73 :)
.

AkinaLieutenant PigeonЧей кварц надежнее?Эммм... если бы хотя бы можно было вести речь о типе кварца... но в данном случае ты имеешь дело с двумя конкретными экземплярами. А чёрная овца везде попасться может. Так что ничего лучше взаимной калибровки, я полагаю, придумать не получится.

guest_rusimportLieutenant Pigeon,
наткнулся недавно на статью (в этом не разбираюсь, но может будет чем полезна)
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Акина, спасибо.
Импорт, спасибо.

Импорт, пруф полезный, спасибо, но только для новеньких. Обрати вниание на мою оговорку:
"M$ ретуширует ее десятилетиями ужЕ"

Нужно полностью отвязаться от железа. Но и не это главное. Есть задача - привять такты процессора к системному времени. Из доступных через API самые достоверные - упомянутые два. Сложность в том, что обладая (мы полагаем так, но альтернатив иных нет) равной resolution, они работают в разных accuracy. Поэтому, привязывать мы можем первый ко второму с частотой, лишь не меньше accuracy второго.

Я усложню задачу... Все это хозяйство надо привязать к двум внешним источникам, данные которых я мечу ужЕ сам. Оба несут свои таймштемпы. Один с accuracy в 1 сек. Второй - с недостоверной accuracy в 0.001 сек.

Да и насрать! Но есть переход через сутки - это раз. И внутренние границы сессий - это два.

Т.е. у обоих последний отсчет в сессии не может быть позже, скажем, 21:45. Если один из трех (первый 1 сек, второй - 0.001 сек и мой с кучей нулей на номерном знаке) покажет не то, то следуют ошибка деления, переполнение и пр...

Проверять точность и дрифт я на кажлм отсчете не могу - затраты. Мне скорострельность нужна.

Я ушел от Акса вообще. Тормозит. Пишу базу в лоб в текстовый файл. Готовлюсь перейти на бинарник.
Для послеследующей аналитики - переходник сваять не проблема. А в онлайне СИНХРОННОМ под VB6 не пропустить эвент - вот задача.
.

Lieutenant Pigeon... в онлайне СИНХРОННОМ под VB6 не пропустить эвент - вот задача.Это я ужЕ про скорострельность. Не про дрифт...
.

Да, вот еще...

Если кто интересуется темой, то ...

... на нескольких машинах я давно, с частотой 3 сек, мониторю показания QueryPerformanceFrequency через As Currency, но не BigInt. Т.е. поправка на 10^4

Могу утверждать, что внутри одной машиносессии (т.е. от ресета до ресета) в рамках запущенного процесса частота не меняется.

Между ресетами - может прыгать на килогерц-другой. Но - не обязательно.

Вот лог с одной из машин:


Показательно, что если частота (отсчет ее ?!) прыгает, то только на первом такте запуска монитора, но ни как не в процессе его работы.

Осталось только написать батник, который внутри одной машиносессии будет перезапускать монитор.

Понятно ,что эта частота несколько абстрактная вещь, но, по крайней мере, имеем уверенность что ее можно использовать внутри суток...

Как-то так...
.