Microsoft MVP성태의 닷넷 이야기
Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점 [링크 복사], [링크+제목 복사],
조회: 5689
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
Windows: 120. 윈도우 운영체제의 시간 함수 (1) - GetTickCount와 timeGetTime의 차이점
; https://www.sysnet.pe.kr/2/0/11063

Windows: 121. 윈도우 운영체제의 시간 함수 (2) - Sleep 함수의 동작 방식
; https://www.sysnet.pe.kr/2/0/11065

Windows: 122. 윈도우 운영체제의 시간 함수 (3) - QueryInterruptTimePrecise, QueryInterruptTime 함수
; https://www.sysnet.pe.kr/2/0/11066

Windows: 123. 윈도우 운영체제의 시간 함수 (4) - RTC, TSC, PM Clock, HPET Timer
; https://www.sysnet.pe.kr/2/0/11067

Windows: 124. 윈도우 운영체제의 시간 함수 (5) - TSC(Time Stamp Counter)와 QueryPerformanceCounter
; https://www.sysnet.pe.kr/2/0/11068

Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점
; https://www.sysnet.pe.kr/2/0/13802




Windows - GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점

우선, 이 차이점을 이해하려면 아래의 글을 먼저 읽어주시고. ^^

윈도우 운영체제의 시간 함수 (1) - GetTickCount와 timeGetTime의 차이점
; https://www.sysnet.pe.kr/2/0/11063

위의 글을 이해했다면 이제 GetSystemTimeAsFileTime의 동작 방식도 쉽게 알 수 있습니다.

GetSystemTimeAsFileTime function (sysinfoapi.h)
; https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimeasfiletime

즉, GetSystemTimeAsFileTime은 timer interrupt가 tick을 업데이트하는 주기로 시간이 업데이트되는 것인데요, 따라서 다음과 같은 식으로 테스트해 보면,

#include <vector>
#include <Windows.h>

using namespace std;

ULONGLONG SubtractFileTime(const FILETIME& ftA, const FILETIME& ftB)
{
    ULARGE_INTEGER a, b;
    a.LowPart = ftA.dwLowDateTime;
    a.HighPart = ftA.dwHighDateTime;

    b.LowPart = ftB.dwLowDateTime;
    b.HighPart = ftB.dwHighDateTime;

    return (a.QuadPart - b.QuadPart);
}

int main()
{
    int count = 1000000;
    vector<FILETIME> ticks;

    for (int i = 0; i < count; i++)
    {
        FILETIME ft;
        GetSystemTimeAsFileTime(&ft);

        ticks.push_back(ft);
    }

    FILETIME oldTime = ticks[0];
    ULONGLONG elapsed;
    for (int i = 1; i < count; i++)
    {
        elapsed = SubtractFileTime(ticks[i], oldTime);
        oldTime = ticks[i];

        if (elapsed != 0)
        {
            printf("%lld\n", elapsed);
        }
    }
}

/* 출력 결과: Current timer interval" == 1ms인 경우
10049
9912
10000
10023
9990
9992
10069
9931
9990
10007
*/

대충, 10,000 범위로 값이 툭툭 튀고 있는데요, 저 값의 정확한 의미는 QueryPerformanceFrequency가 반환한 값이 있어야 해석이 가능합니다.

bool g_IsHighResolution = false;

__int64 GetQPCFreq()
{
    LARGE_INTEGER qpcRate;
    g_IsHighResolution = QueryPerformanceFrequency(&qpcRate); // 대개의 경우 g_IsHighResolution == true
    return qpcRate.QuadPart;
}

__int64 frequency = GetQPCFreq();
printf("QPC frequency: %lld\n", frequency); // 출력 결과: QPC frequency: 10000000

위의 결과에 따라 GetSystemTimeAsFileTime이 반환한 값의 1 단위는 1 / 10,000,000 초(0.1 마이크로 초, 100 나노 초)에 해당합니다. 따라서 10,000 주기로 값이 튀는 것은 1 / 1,000초, 즉 1ms 주기로 발생하는 timer interrupt마다 GetSystemTimeAsFileTime의 값이 바뀐다는 것을 의미합니다.

만약 timer interrupt 주기가 15.6ms인 경우라면, 약 156,000 단위로 값이 튀는 현상을 볼 수 있습니다.

결국 timer interrupt가 발생한 바로 그 순간에 100 나노 초 단위의 정밀도로 그 시간을 보관하게 되지만, 이후 1ms가 지나기까지는 그 값이 변경되지 않다가, 1ms가 지나서야 다시 그 시점의 시간을 100 나노 초 단위로 보여주는 식입니다.




GetSystemTimePreciseAsFileTime은, 예상할 수 있겠지만 Precise라는 단어가 들어간 것에서 좀 더 정밀한 시간을 나타낼 것이라고 예상할 수 있습니다.

GetSystemTimePreciseAsFileTime function (sysinfoapi.h)
; https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime

실제로, 위의 예제 코드를 GetSystemTimeAsFileTime을 호출하는 것만 GetSystemTimePreciseAsFileTime으로 바꿔 실행해 보면,

int main()
{
    int count = 10;
    vector<FILETIME> ticks;

    for (int i = 0; i < count; i++)
    {
        FILETIME ft;
        GetSystemTimePreciseAsFileTime(&ft);

        ticks.push_back(ft);
    }

    // ...[생략]...
}

/* 출력 결과: Current timer interval"의 설정과 무관하게!
3
2
1
2
1
1
1

대략 0.1us마다 값이 튀는 것을 볼 수 있습니다. 즉 timer interrupt가 발생하는 것과 무관하게 현재 시간을 100ns 단위의 정밀도로 반환하고 있는 것입니다.

이 함수는 Windows 8 / Windows Server 2012부터 구현하고 있는데요, 이게 어떻게 가능하게 된 것일까요? ^^ 일단 윈도우 소스코드가 없어 구체적으로 어떻게 구현돼 있는지는 알 수 없지만, 그냥 제 추측으로 적어보자면... ^^

아마도, timer interrupt가 발생하는 주기로 기존처럼 시간을 업데이트하고 있지만, 바로 그 시점의 rdtsc 값을 보관한 다음 이후 GetSystemTimePreciseAsFileTime을 호출할 때 rdtsc의 변화를 계산해 마지막 timer interrupt가 발생한 시점의 값과 더해 반환하는 식이... 아닐까 싶습니다.

물론, 그렇게 하면 요즘 CPU의 경우 GHz 주기로 시간 정밀도가 나올 수 있는데요, 하지만 근래의 Windows 운영체제는 그 값을 정규화시켜 100ns에 맞춰서 제공하고 있습니다.

아무튼, 1 ~ 15.6ms 정도의 정밀도로 상관없다면 GetSystemTimeAsFileTime을 사용하고, 그 이상의 정밀도가 필요하다면 (보통) 0.1us 정밀도를 갖는 GetSystemTimePreciseAsFileTime을 사용하면 됩니다. (주의할 사항이 있는데, 일부 시스템에서는 Precise 함수가 정상적인 값을 반환하지 않는 문제가 있으므로, GetSystemTimeAsFileTime으로 보완하는 코드가 필요합니다.)




참고로, QueryPerformanceFrequency 함수가 대개의 경우 10000000을 반환하지만 환경에 따라 다른 값을 반환하기도 합니다. 가령 예전에 질문하셨던 분도 그렇고, 아래의 글을 테스트할 때만 해도,

윈도우 운영체제의 시간 함수 (5) - TSC(Time Stamp Counter)와 QueryPerformanceCounter
; https://www.sysnet.pe.kr/2/0/11068

QueryPerformanceFrequency가 3328129를 반환했었는데요, 이 차이는 Windows 10 build 1809부터 바뀐 것이니 유의하시기 바랍니다.

Windows 10부터 바뀐 QueryPerformanceFrequency, QueryPerformanceCounter
; https://www.sysnet.pe.kr/2/0/13035





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/7/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...
NoWriterDateCnt.TitleFile(s)
13566정성태2/27/20249535오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20248633닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/202410152Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20249638디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20249337오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/202410137닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/202410186디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/202411003오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/202410174닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20249048Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20249424Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20249637닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20249064VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20248607닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20248723닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20249811닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/202410254Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/202411231개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/202410796개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/202410452개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/202410143Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20249679닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20249330오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20249760Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20248831오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20249591VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...