Microsoft MVP성태의 닷넷 이야기
Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점 [링크 복사], [링크+제목 복사],
조회: 5738
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12083정성태12/17/201922250Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920537오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922388개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919532.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921415오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921224Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920329Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918838디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919626디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919278디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920850Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917655오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921159오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923082오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919473디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928128디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919541디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919189디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917504디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920404오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919356디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918859디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919294Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201920885디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201920047디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201920700디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...