問(wèn)題描述
我在 Windows 7 上使用 GetSystemTimeAdjustment 函數(shù)運(yùn)行了一些測(cè)試，得到了一些我無(wú)法解釋的有趣結(jié)果.據(jù)我所知，如果系統(tǒng)時(shí)間是定期同步的，則此方法應(yīng)該返回，如果是，則以哪個(gè)間隔和以哪個(gè)增量更新(參見(jiàn) MSDN 上的 GetSystemTimeAdjustment 函數(shù)).
從這里我遵循，如果我查詢系統(tǒng)時(shí)間，例如使用 GetSystemTimeAsFileTime 重復(fù)我應(yīng)該要么沒(méi)有變化(系統(tǒng)時(shí)鐘尚未更新)，要么是變化的倍數(shù)GetSystemTimeAdjustment 檢索到的增量.問(wèn)題一:這個(gè)假設(shè)正確嗎?
現(xiàn)在考慮以下測(cè)試代碼:
#include #include #include int main(){FILETIME 文件開(kāi)始；GetSystemTimeAsFileTime(&fileStart);ULARGE_INTEGER 開(kāi)始；start.HighPart = fileStart.dwHighDateTime;start.LowPart = fileStart.dwLowDateTime;for (int i=20; i>0; --i){FILETIME時(shí)間戳1；ULARGE_INTEGER ts1;GetSystemTimeAsFileTime(&timeStamp1);ts1.HighPart = timeStamp1.dwHighDateTime;ts1.LowPart = timeStamp1.dwLowDateTime;std::cout <<時(shí)間戳:" <<std::setprecision(20) <<(double)(ts1.QuadPart - start.QuadPart)/10000000 <<std::endl;}DWORD dwTimeAdjustment = 0, dwTimeIncrement = 0, dwClockTick;BOOL fAdjustmentDisabled = TRUE;GetSystemTimeAdjustment(&dwTimeAdjustment, &dwTimeIncrement, &fAdjustmentDisabled);std::cout <<"
時(shí)間調(diào)整禁用:" <<f 調(diào)整禁用<<"
時(shí)間調(diào)整:" <<(double)dwTimeAdjustment/10000000<<"
時(shí)間增量:" <<(double)dwTimeIncrement/10000000 <<std::endl;} 它在一個(gè)循環(huán)中需要 20 個(gè)時(shí)間戳并將它們打印到控制臺(tái).最后，它打印系統(tǒng)時(shí)鐘更新的增量.我希望循環(huán)中打印的時(shí)間戳之間的差異是此增量的 0 或倍數(shù).但是，我得到這樣的結(jié)果:
時(shí)間戳:0時(shí)間戳:0.0025000000000000001時(shí)間戳:0.0074999999999999997時(shí)間戳:0.01時(shí)間戳:0.012500000000000001時(shí)間戳:0.014999999999999999時(shí)間戳:0.017500000000000002時(shí)間戳:0.022499999999999999時(shí)間戳:0.025000000000000001時(shí)間戳:0.0275時(shí)間戳:0.029999999999999999時(shí)間戳:0.032500000000000001時(shí)間戳:0.035000000000000003時(shí)間戳:0.040000000000000001時(shí)間戳:0.042500000000000003時(shí)間戳:0.044999999999999998時(shí)間戳:0.050000000000000003時(shí)間戳:0.052499999999999998時(shí)間戳:0.055時(shí)間戳:0.057500000000000002時(shí)間調(diào)整禁用:0時(shí)間調(diào)整:0.0156001時(shí)間增量:0.0156001因此看起來(lái)系統(tǒng)時(shí)間是使用大約 0.0025 秒而不是 GetSystemTimeAdjustment 返回的 0.0156 秒的間隔更新的.
問(wèn)題二:這是什么原因?
GetSystemTimeAsFileTimeAPI 提供對(duì)文件時(shí)間格式的系統(tǒng)掛鐘的訪問(wèn).
64 位 FILETIME 結(jié)構(gòu)以 100ns 為單位接收系統(tǒng)時(shí)間作為 FILETIME，該時(shí)間自 1601 年 1 月 1 日起已過(guò)期.對(duì) GetSystemTimeAsFileTime 的調(diào)用通常需要 10 ns 到 15 ns.
為了調(diào)查此 API 提供的系統(tǒng)時(shí)間的真實(shí)準(zhǔn)確性，需要討論與時(shí)間值一起出現(xiàn)的粒度.換句話說(shuō):系統(tǒng)時(shí)間多久更新一次?第一個(gè)估計(jì)值由隱藏的 API 調(diào)用提供:
NTSTATUS NtQueryTimerResolution(OUT PULONG MinimumResolution,OUT PULONG 最大分辨率，OUT PULONG 實(shí)際分辨率)；NtQueryTimerResolution 由本地 Windows NT 庫(kù) NTDLL.DLL 導(dǎo)出.本次調(diào)用上報(bào)的ActualResolution以100ns為單位表示系統(tǒng)時(shí)間的更新周期，不一定與中斷周期匹配.該值取決于硬件平臺(tái).常見(jiàn)硬件平臺(tái)為 ActualResolution 報(bào)告 156,250 或 100,144；較舊的平臺(tái)可能會(huì)報(bào)告更大的數(shù)字；較新的系統(tǒng)，尤其是在支持 HPET(高精度事件計(jì)時(shí)器)或 常量/不變 TSC 時(shí)，可能會(huì)為 ActualResolution 返回 156,001.
這是控制系統(tǒng)的心跳之一.MinimumResolution 和 ActualResolution 與多媒體計(jì)時(shí)器配置相關(guān).
ActualResolution 可以通過(guò) API 調(diào)用設(shè)置
NTSTATUS NtSetTimerResolution(IN ULONG RequestedResolution,在布爾集合中，OUT PULONG 實(shí)際分辨率)；或通過(guò)多媒體定時(shí)器界面
MMRESULT timeBeginPeriod(UINT uPeriod);從允許的范圍推導(dǎo)出 uPeriod 的值
MMRESULT timeGetDevCaps(LPTIMECAPS ptc, UINT cbtc);填充結(jié)構(gòu)
typedef struct {UINT wPeriodMin;UINT wPeriodMax;TIMECAPS;wPeriodMin 的典型值為 1 ms，wPeriodMax 的典型值為 1,000,000 ms.
在這里查看最小值/最大值時(shí)存在一個(gè)不幸的誤解:
- wPeriodMin 定義了最短時(shí)間段，在此上下文中很清楚.
- MinimumResolution 另一方面由
NtQueryTimerResolution返回指定分辨率.可獲得的最低分辨率(MinimumResolution)可達(dá)20 ms左右，而可獲得的最高分辨率(MaximumResolution)可達(dá)0.5 ms.但是，無(wú)法通過(guò)timeBeginPeriod訪問(wèn) 0.5 毫秒的結(jié)果.
多媒體定時(shí)器接口處理周期，NtQueryTimerResolution() 處理分辨率(周期的倒數(shù)).
總結(jié): GetSystemTimeAdjustment 不是要查看的函數(shù).此功能僅說(shuō)明如何以及是否完成時(shí)間更改.根據(jù)多媒體定時(shí)器界面timeBeginPeriod的設(shè)置，時(shí)間進(jìn)度可能會(huì)更頻繁，更小部分.使用 NtQueryTimerResolution 接收實(shí)際時(shí)間增量.請(qǐng)注意，多媒體計(jì)時(shí)器 API 的設(shè)置確實(shí)會(huì)影響這些值.(例如:當(dāng)媒體播放器播放視頻時(shí)，時(shí)間越來(lái)越短.)
我診斷出 Windows 時(shí)間在很大程度上很重要.部分結(jié)果可以在此處找到.
注意:時(shí)間調(diào)整:0.0156001在您的系統(tǒng)上使用 HPET 和/或 constant/invariant TSC 清楚地識(shí)別 Windows VISTA 或更高版本.
實(shí)施:如果你想抓住時(shí)間的轉(zhuǎn)變:
FILETIME FileTime,LastFileTime;長(zhǎng)長(zhǎng)的到期時(shí)間，最后時(shí)間；長(zhǎng) FileTimeTransitionPeriod;GetSystemTimeAsFileTime(&FileTime);for (int i = 0; i <20; i++) {LastFileTime.dwLowDateTime = FileTime.dwLowDateTime;while (FileTime.dwLowDateTime == LastFileTime.dwLowDateTime) GetSystemTimeAsFileTime(&FileTime);//足以只看低部分來(lái)捕捉過(guò)渡CopyMemory(&DueTime,&FileTime,sizeof(FILETIME));CopyMemory(&LastTime,&LastFileTime,sizeof(FILETIME));FileTimeTransitionPeriod = (long)(DueTime-LastTime);fprintf(stdout,"transition period: % 7.4lf ms)
",(double)(FileTimeTransitionPeriod)/10000);}//警告:此代碼以 20 個(gè)文件時(shí)間增量消耗 100% 的 cpu.//在 15.625 毫秒的標(biāo)準(zhǔn)文件時(shí)間增量下，這對(duì)應(yīng)于 312.5 毫秒！但是:當(dāng)文件時(shí)間轉(zhuǎn)換非常短時(shí)(例如由 timeBeginPeriod(wPeriodMin) 設(shè)置)任何輸出，如 fprintf 或 std::cout 可能會(huì)破壞結(jié)果，因?yàn)樗鼤?huì)延遲循環(huán).在這種情況下，我建議將 20 個(gè)結(jié)果存儲(chǔ)在一個(gè)數(shù)據(jù)結(jié)構(gòu)中，然后再進(jìn)行輸出.
并且:文件時(shí)間轉(zhuǎn)換可能并不總是相同的.很可能是文件時(shí)間增量與更新周期不匹配.請(qǐng)參閱上面的鏈接以獲取有關(guān)此行為的更多詳細(xì)信息和示例.
調(diào)用 timeBeginPeriod 時(shí)要小心，因?yàn)轭l繁調(diào)用會(huì)顯著影響系統(tǒng)時(shí)鐘 MSDN.此行為適用于 Windows 版本 7.
對(duì)timeBeginPeriod/timeEndPeriod 或NtSetTimerResolution 的調(diào)用可能會(huì)改變系統(tǒng)時(shí)間與ActualResolution 一樣多.經(jīng)常這樣做會(huì)導(dǎo)致系統(tǒng)時(shí)間發(fā)生相當(dāng)大的變化.但是，當(dāng)在系統(tǒng)時(shí)間轉(zhuǎn)換時(shí)或附近進(jìn)行調(diào)用時(shí)，偏差要小得多.對(duì)于要求苛刻的應(yīng)用程序(如 NTP 客戶端)，建議在調(diào)用上述函數(shù)之前輪詢系統(tǒng)時(shí)間轉(zhuǎn)換/增量.當(dāng)系統(tǒng)時(shí)間進(jìn)程發(fā)生意外跳轉(zhuǎn)時(shí)，很難同步到 NTP 服務(wù)器.
I ran some tests using the GetSystemTimeAdjustment function on Windows 7, and got some interesting results which I cannot explain. As fas as I understand, this method should return if the system time is synchronized periodically and if it is, at which interval and with which increment it is updated (see GetSystemTimeAdjustment function on MSDN).
From this I follow that if I query the system time for example using GetSystemTimeAsFileTime repeatingly I should either get no change (the system clock has not been updated), or a change which is a multiple of the increment retrieved by GetSystemTimeAdjustment. Question one: Is this assumption correct?
Now consider the following testing code:
#include <windows.h>
#include <iostream>
#include <iomanip>
int main()
{
FILETIME fileStart;
GetSystemTimeAsFileTime(&fileStart);
ULARGE_INTEGER start;
start.HighPart = fileStart.dwHighDateTime;
start.LowPart = fileStart.dwLowDateTime;
for (int i=20; i>0; --i)
{
FILETIME timeStamp1;
ULARGE_INTEGER ts1;
GetSystemTimeAsFileTime(&timeStamp1);
ts1.HighPart = timeStamp1.dwHighDateTime;
ts1.LowPart = timeStamp1.dwLowDateTime;
std::cout << "Timestamp: " << std::setprecision(20) << (double)(ts1.QuadPart - start.QuadPart) / 10000000 << std::endl;
}
DWORD dwTimeAdjustment = 0, dwTimeIncrement = 0, dwClockTick;
BOOL fAdjustmentDisabled = TRUE;
GetSystemTimeAdjustment(&dwTimeAdjustment, &dwTimeIncrement, &fAdjustmentDisabled);
std::cout << "
Time Adjustment disabled: " << fAdjustmentDisabled
<< "
Time Adjustment: " << (double)dwTimeAdjustment/10000000
<< "
Time Increment: " << (double)dwTimeIncrement/10000000 << std::endl;
}
It takes 20 timestamps in a loop and prints them to the console. In the end it prints the increment with which the system clock is updated. I would expect the differences between the timestamps printed in the loop to be either 0 or multiples of this increment. However, I get results like this:
Timestamp: 0
Timestamp: 0.0025000000000000001
Timestamp: 0.0074999999999999997
Timestamp: 0.01
Timestamp: 0.012500000000000001
Timestamp: 0.014999999999999999
Timestamp: 0.017500000000000002
Timestamp: 0.022499999999999999
Timestamp: 0.025000000000000001
Timestamp: 0.0275
Timestamp: 0.029999999999999999
Timestamp: 0.032500000000000001
Timestamp: 0.035000000000000003
Timestamp: 0.040000000000000001
Timestamp: 0.042500000000000003
Timestamp: 0.044999999999999998
Timestamp: 0.050000000000000003
Timestamp: 0.052499999999999998
Timestamp: 0.055
Timestamp: 0.057500000000000002
Time Adjustment disabled: 0
Time Adjustment: 0.0156001
Time Increment: 0.0156001
So it appears that the system time is updated using an interval of about 0.0025 seconds and not 0.0156 seconds as return by GetSystemTimeAdjustment.
Question two: What is the reason for this?
The GetSystemTimeAsFileTimeAPI provides access to the system's wall clock in file time format.
A 64-bit FILETIME structure receives the system time as FILETIME in 100ns units, which have been expired since Jan 1, 1601. The call to GetSystemTimeAsFileTime typically requires 10 ns to 15 ns.
In order to investigate the real accuracy of the system time provided by this API, the granularity that comes along with the time values needs to be discussed. In other words: How often is the system time updated? A first estimate is provided by the hidden API call:
NTSTATUS NtQueryTimerResolution(OUT PULONG MinimumResolution,
OUT PULONG MaximumResolution,
OUT PULONG ActualResolution);
NtQueryTimerResolution is exported by the native Windows NT library NTDLL.DLL. The ActualResolution reported by this call represents the update period of the system time in 100 ns units, which does not necessarily match the interrupt period. The value depends on the hardware platform. Common hardware platforms report 156,250 or 100,144 for ActualResolution; older platforms may report even larger numbers; newer systems, particulary when HPET (High Precision Event Timer) or constant/invariant TSC are supported, may return 156,001 for ActualResolution.
This is one of the heartbeats controlling the system. The MinimumResolution and the ActualResolution are relevant for the multimedia timer configuration.
The ActualResolution can be set by using the API call
NTSTATUS NtSetTimerResolution(IN ULONG RequestedResolution,
IN BOOLEAN Set,
OUT PULONG ActualResolution);
or via the multimedia timer interface
MMRESULT timeBeginPeriod(UINT uPeriod);
with the value of uPeriod derived from the range allowed by
MMRESULT timeGetDevCaps(LPTIMECAPS ptc, UINT cbtc );
which fills the structure
typedef struct {
UINT wPeriodMin;
UINT wPeriodMax;
} TIMECAPS;
Typical values are 1 ms for wPeriodMin and 1,000,000 ms for wPeriodMax.
There is an unfortunate misinterpretation when looking an the min/max values here:
- wPeriodMin defines the minimum period, which is clear in this context.
- MinimumResolution returned by
NtQueryTimerResolutionon the other hand specifies a resolution. The lowest obtainable resolution (MinimumResolution) is in the range of up to about 20 ms, while the highest obtainable resolution (MaximumResolution) can be 0.5 ms. However, the 0.5 ms resulution is not accessable through a oftimeBeginPeriod.
The multimedia timer interface handles periods and NtQueryTimerResolution() handles resolutions (reciprocal value of period).
Summary: GetSystemTimeAdjustment is not the function to look at. This function only tells how and if time-changes are done. Depending on the setting of the multimedia timer interface timeBeginPeriod, the progress of time may be done more often and in smaller portions. Use NtQueryTimerResolution to receive the actual time increment. And be aware that the setting of the multimedia timer API does influence the values. (Example: When the media player is showing a video, the times are getting short.)
I diagnosed windows time matters to a large extent. Some of the results can be found here.
Note: Time Adjustment: 0.0156001 clearly identifies windows VISTA or higher with HPET and/or constant/invariant TSC on your system.
Implementation: If you want to catch the time transition:
FILETIME FileTime,LastFileTime;
long long DueTime,LastTime;
long FileTimeTransitionPeriod;
GetSystemTimeAsFileTime(&FileTime);
for (int i = 0; i < 20; i++) {
LastFileTime.dwLowDateTime = FileTime.dwLowDateTime;
while (FileTime.dwLowDateTime == LastFileTime.dwLowDateTime) GetSystemTimeAsFileTime(&FileTime);
// enough to just look at the low part to catch the transition
CopyMemory(&DueTime,&FileTime,sizeof(FILETIME));
CopyMemory(&LastTime,&LastFileTime,sizeof(FILETIME));
FileTimeTransitionPeriod = (long)(DueTime-LastTime);
fprintf(stdout,"transition period: % 7.4lf ms)
",(double)(FileTimeTransitionPeriod)/10000);
}
// WARNING: This code consumes 100% of the cpu for 20 file time increments.
// At the standard file time increment of 15.625 ms this corresponds to 312.5ms!
But: When the filetime transition is very short (e.g. set by timeBeginPeriod(wPeriodMin)) any output like fprintf or std::cout might destroy the result because it delays the loop. In such cases I'd recommend to store the 20 results in a data structure and do the output afterwards.
And: The filetime transition may not always be the same. It may well be that the file time increment does not match the update period. See the link above to get more details and examples for this bahavior.
Edit: Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock MSDN. This behavior applies up to Windows version 7.
Calls to timeBeginPeriod/timeEndPeriod or NtSetTimerResolution may change the system time by as much as ActualResolution. Doing it very often results in considerable changes of the system time. However, when the calls are made at or near the transition of the system time, deviations are much less. Polling for a system time transition/increment ahead of calls to the above function is advised for demanding applications like NTP clients. Synchronizing to an NTP server is difficult when unwanted jumps in the systemtime progess occurs.
這篇關(guān)于Windows 7 計(jì)時(shí)功能 - 如何正確使用 GetSystemTimeAdjustment?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！