Windows 소프트 리얼타임 실전 가이드 - 지연을 줄이기 위한 체크리스트

이 글에서 다루는 것은 특별한 리얼타임 확장을 넣은 Windows가 아니라 평범한 Windows 10 / 11 입니다. 대상은 일반적인 데스크톱 PC나 노트북 위에서 도는 user-mode의 일반 앱 입니다.

여기서 목표로 하는 것은 hard real-time 보증이 아닙니다. 평범한 Windows라도 설계, 대기 방법, 우선순위, 전원 설정, 계측을 갖춰 두면 soft real-time으로 꽤 실용적인 수준 까지 끌어올 수 있습니다.

이번에는 항목을 빠짐없이 나열하기보다 무엇을 재검토하면 되는지 바로 파악할 수 있는 구성 으로 만들었습니다. 먼저 4절의 체크리스트를 보면 재검토할 포인트가 대략 보입니다.

1. 먼저 결론 (한마디로)

• 평범한 Windows에서 목표로 하는 것은 hard real-time 보증이 아니라 지연과 지터를 줄이고 deadline miss를 줄이는 것
• 먼저 재검토할 것은 우선순위 값보다 주기 스레드 안에 무엇을 넣고 있는지
• 매 주기 반드시 지나가는 시간에 엄격한 처리는 fast path, 저장·통신·UI처럼 조금 늦어도 되는 처리는 slow path 로 나눈다
• fast path에서는 Sleep 의존 대기, 블로킹 I/O, 매번의 할당·해제, 무제한 큐를 피한다
• 음성이나 영상 같은 연속 스트림에서는 먼저 MMCSS 를 검토한다
• 실운영에서는 AC 전원, 전원 모드, timer resolution, power throttling, 백그라운드 부하 가 영향을 준다
• 평가는 평균값만이 아니라 p99 / p99.9 / max / miss 횟수 / queue 깊이 / DPC / ISR / page fault 로 본다

실무에서의 순서는 대략 다음과 같습니다.

1. 주기 루프를 Sleep 의존에서 뗀다
2. fast path와 slow path를 분리한다
3. 큐를 고정 길이로 하고 넘쳤을 때의 방침을 정한다
4. fast path에서 I/O, 할당, 무거운 락을 뺀다
5. 필요한 스레드만 우선순위나 MMCSS를 쓴다
6. 평범한 Windows의 전원 설정과 계측을 갖춘다

「평범한 Windows에서 어디를 고치면 덜 늦어질까」를 파악하고 싶다면 이 순서로 보는 것이 명료합니다.

2. 이 글에서 말하는 「평범한 Windows」란 무엇인가

여기서 말하는 「평범한 Windows」는 Windows 10 / 11의 일반적인 PC 를 가리킵니다. 특별한 리얼타임 확장이나 전용 OS를 쓰지 않고, Windows가 표준으로 가진 API와 설정의 범위에서 어디까지 안정화할 수 있는지를 본다, 라는 입장입니다.

flowchart TB
    scope["이 글의 대상"] --> s1["Windows 10 / 11의 일반적인 PC"]
    scope --> s2["user-mode의 일반 앱"]
    scope --> s3["표준 API와 표준 설정을 중심으로 사용"]
    scope --> s4["평범한 데스크톱 PC / 노트북"]

    out["이 글의 대상 외"] --> o1["전용 RTOS나 RT 확장"]
    out --> o2["커널 드라이버 주도의 제어"]
    out --> o3["FPGA나 MCU로 전면 이관하는 구성"]

2.1. 대상 범위

대상으로 하는 것은 예컨대 다음과 같습니다.

• Windows 10 / 11 위에서 도는 C++ / C#의 user-mode 앱
• 음성, 영상, 계측, 장치 제어, 주기 처리처럼 「덜 늦는 것」이 필요한 소프트웨어
• 일반 데스크톱 PC, 워크스테이션, 노트북

즉, 「평범하게 배포 가능한 Windows 앱으로서 어디까지 버틸 수 있을까」를 다룹니다.

2.2. 대상 외

한편, 이 글의 중심에서 빠지는 것도 있습니다.

• hard real-time 보증
• 전용 RTOS나 리얼타임 확장 제품의 도입
• 커널 드라이버나 자체 드라이버를 주인공으로 하는 설계
• FPGA, MCU, 전용 컨트롤러에 시간에 엄격한 부분을 전면 이관하는 구성

요건이 엄해지면 이런 선택지도 필요해집니다. 다만 처음부터 거기로 가기 전에 평범한 Windows에서 재현 가능한 개선 을 쌓을 가치는 꽤 있습니다.

3. Windows에서의 소프트 리얼타임이란 무엇인가

3.1. 목표로 하는 것

평범한 Windows에서 노리는 것은 다음과 같은 상태입니다.

• 평상시 지연을 낮게 유지
• 지터를 작게
• 가끔 지연 스파이크가 와도 망가지지 않게
• 기한을 못 맞춘 횟수를 관측 가능하게

여기서 말하는 soft real-time은 「절대로 늦지 않는다」가 아니라 덜 늦고, 늦으면 알 수 있고, 늦어도 안 망가진다 를 지향하는 사고방식입니다.

3.2. 이 글에서 쓰는 말

먼저 이 3개만 잡아두면 읽기 쉬워집니다.

예컨대 1ms마다 돌리고 싶은 처리가 1.8ms 뒤에 시작됐다면 그 0.8ms가 지연입니다. 그게 매번 1.0ms가 아니라 0.9ms, 1.3ms, 2.1ms처럼 흔들리면 그게 지터입니다.

3.3. 어디부터 어려워지는가

평범한 Windows의 user-mode 앱만으로 엄해지기 시작하는 것은 예컨대 다음과 같은 요구입니다.

• 기한 위반 제로를 보증하고 싶다
• 수백 마이크로초 이하를 장시간 안정적으로 지키고 싶다
• 무거운 GUI, 통신, 스토리지와 고빈도 주기 처리를 전부 동거시키고 싶다
• 배터리 구동이나 절전 우선 상태에서 엄격한 주기를 지키고 싶다
• 드라이버나 디바이스 유래의 스파이크도 용납되지 않는다

이 정도가 되면 평범한 Windows 단독으로는 버겁습니다. 그 경우는 정말 시간에 엄격한 부분만 펌웨어, 전용 컨트롤러, FPGA, 별도 RTOS로 옮기는 것도 고려하는 편이 좋습니다.

4. 먼저 볼 체크리스트

이 절은 「무엇을 조심해야 하는지」를 먼저 파악하기 위한 절 입니다. 우선 다음 표만 보면 재검토할 위치의 감이 잡힙니다.

4.1. 전체 그림

flowchart TB
    start["주기 처리가 늦는다"] --> c1["대기 방법을 확인"]
    c1 --> c2["fast path에 무거운 처리가 있는지 확인"]
    c2 --> c3["큐 상한과 넘침 방침을 확인"]
    c3 --> c4["우선순위와 MMCSS 사용법을 확인"]
    c4 --> c5["전원 모드와 timer / power throttling 확인"]
    c5 --> c6["그래도 흔들리면 DPC / ISR / page fault를 계측"]

이하 각 항목을 순서대로 봅니다.

4.2. 주기 루프는 Sleep 의존으로 하지 않는다

먼저 확인하고 싶은 곳이 여기입니다. Sleep(1)은 「1ms 딱 기다림」이 아니라 적어도 1ms 이상 기다림 입니다. 거기에 Step()의 실행 시간도 더해지므로 주기의 어긋남이 그대로 쌓입니다.

flowchart LR
    a["Sleep(1)"] --> b["예상보다 길게 기다릴 수 있음"]
    b --> c["Step의 실행 시간이 더해짐"]
    c --> d["주기 어긋남이 누적됨"]

주기 처리는 상대 시간이 아니라 절대 기한 으로 돌리는 편이 안정적입니다. 생각은 다음 형태입니다.

int64_t next = QpcNow() + periodTicks;

while (running)
{
    WaitUntil(next - wakeMarginTicks);   // event / waitable timer
    while (QpcNow() < next)
    {
        CpuRelax();                      // 마지막만 짧게 spin
    }

    int64_t started = QpcNow();
    FastStep();                          // no blocking, no alloc, no heavy lock
    int64_t finished = QpcNow();

    RecordTiming(next, started, finished);

    next += periodTicks;

    while (finished > next)
    {
        ++missedDeadlines;
        next += periodTicks;
    }
}

포인트는 2가지입니다.

• 매번 next = now + period로 하지 않는다
• 늦었을 때 어떻게 할지 미리 정한다

평범한 Windows에서 안정화하고 싶다면 여기는 꽤 효과가 큽니다.

4.3. fast path와 slow path를 나눈다

구성상 가장 효과가 큰 것은 시간에 엄격한 처리와 조금 늦어도 되는 처리를 나누는 것 입니다.

• fast path 매 주기 반드시 지나가며 짧게 끝나야 하는 처리
• slow path 저장, 통신, 정리, 집계, UI 등 조금 늦어도 허용되는 처리

flowchart LR
    dev["디바이스 / 타이머 / 이벤트"] --> fast["fast path: 취득 / 제어 / 최소 복사"]
    fast --> queue["고정 길이 큐"]
    queue --> slow["slow path: 정리 / 저장 / 송신 / UI"]
    fast --> stat["시각 기록 / miss 기록"]
    stat --> slow

fast path에서 하는 건 다음으로만 좁힙니다.

• 데이터 취득
• 제어값 계산
• 최소 복사
• 타임스탬프
• 큐 투입
• miss나 overrun 기록

그 외는 slow path로 보내는 편이 안정적입니다. 평범한 Windows에서 소프트 리얼타임을 노린다면 먼저 이 분리가 토대 입니다.

4.4. 큐는 고정 길이로, 넘쳤을 때의 방침을 정한다

「늦으면 큐에 쌓으면 된다」고 생각하면 문제를 뒤로 미루기 쉬워집니다. 무제한 큐는 언뜻 안전해 보여도 실제로는 지연을 보이지 않게 할 뿐 이 되기 쉽습니다.

flowchart LR
    input["fast path가 데이터 생성"] --> q{"고정 길이 큐에 여유 있는가"}
    q --> enq["여유 있음: 그대로 투입"]
    q --> policy["여유 없음: 방침 적용"]
    policy --> latest["최신값 우선: 오래된 데이터 버림"]
    policy --> strict["결손 불가: 에러 / 정지 / 알람"]
    policy --> logonly["로그용: 드롭 수 기록"]

미리 정해 두고 싶은 건 다음 3개입니다.

• 큐 상한
• 넘쳤을 때의 방침
• 넘친 사실을 어떻게 기록할지

예컨대 최신값만 의미가 있으면 오래된 것을 버리는 쪽이 자연스럽습니다. 한편 결손이 허용되지 않는다면 조용히 늦추기보다 에러로 다루는 편이 나중에 덜 곤란합니다.

4.5. fast path에 무거운 처리를 넣지 않는다

fast path에서 피하고 싶은 것은 꽤 명확합니다.

• 파일 쓰기
• 네트워크 송신
• DB 쓰기
• 무거운 로그 출력
• 매번의 new / malloc / List<T>.Add
• 매번의 문자열 연결이나 ToString()
• 무거운 락
• 첫 접근에서 페이지 폴트를 부르기 쉬운 처리

정리하면 느려질지 모르는 처리를 fast path에 들이지 않는다 는 이야기입니다.

특히 주의하고 싶은 것은 다음 3가지입니다.

1. 할당과 해제 fast path에서는 버퍼를 먼저 확보해 재사용하는 편이 안정적입니다.

2. 블로킹 I/O 개발기에서는 어쩌다 빨라 보여도 본번에서 흔들리기 쉽습니다.

3. 페이지 폴트 기동 시 필요한 메모리에 한 번 만져 두는 것만으로도 차이가 납니다.

필요하다면 VirtualLock을 쓸 장면도 있지만 이건 보조 수단입니다. 우선 fast path 자체를 가볍게 하고, 필요한 메모리를 먼저 준비하는 쪽이 먼저입니다.

4.6. 우선순위는 필요한 스레드만 올린다

우선순위의 기본은 전부를 올리지 않는 것 입니다. 먼저 정말로 시간에 엄격한 스레드만 대상으로 합니다.

사고방식은 대략 다음입니다.

• UI나 일반 워커는 평범한 우선순위
• fast path 스레드만 필요에 따라 올린다
• 저장, 송신, 로그 집약 같은 후방 작업은 background mode를 검토
• 프로세스 전체보다 먼저 스레드 단위로 생각

음성이나 영상 같은 연속 스트림에서는 먼저 MMCSS 를 검토하는 게 자연스럽습니다. MMCSS는 멀티미디어용으로 Windows가 준비한 스케줄링 기능입니다. 단순히 고우선순위로 기울이는 것보다 Windows의 방식에 가깝습니다.

한편 REALTIME_PRIORITY_CLASS는 맨 처음 넣는 설정이 아닙니다. 효과가 나올 수 있긴 하지만 부작용도 커서, 전용기에서 충분히 거동을 확인한 후 정말 필요할 때만 검토하는 편이 안전합니다.

4.7. 타이머, CPU, 전원 설정을 세트로 본다

평범한 Windows에서는 코드만 고쳐도 부족한 경우가 있습니다. 대기 방법, CPU 배치, 전원 설정은 세트로 보는 편이 명료합니다.

확인하고 싶은 점은 다음입니다.

• 경과 시간 계측은 QueryPerformanceCounter / Stopwatch를 쓰고 있는지
• 대기는 디바이스 이벤트, 또는 고정밀 waitable timer를 쓸 수 있는지
• timeBeginPeriod를 쓴다면 필요한 동안만 쓰고 있는지
• CPU 고정이 필요한지 계측 후 판단하고 있는지
• AC 전원, 전원 모드, process power throttling을 확인하고 있는지

CPU에 대해서는 대뜸 hard affinity로 고정하기보다 먼저 SetThreadIdealProcessor나 CPU Sets 같은 느슨한 지정 부터 시작하는 편이 다루기 쉬운 경우가 많습니다. 고정하면 오히려 OS의 탈출구를 줄일 수 있습니다.

4.8. 늦는 것을 보이게 한다

마지막으로 중요한 건 늦은 사실을 숨기지 않는 것 입니다. 주기 위반은 예외로 버리기보다 세서 기록하는 편이 나중에 원인을 쫓기 쉬워집니다.

최소한 다음은 가지고 있으면 유용합니다.

• 예정 시작 시각
• 실제 시작 시각
• 실제 종료 시각
• lateness
• 실행 시간
• missed deadline 횟수
• 연속 missed deadline 횟수
• queue 깊이
• 드롭 수

그래도 큰 스파이크가 사라지지 않으면 앱 바깥도 의심합니다. 평범한 Windows에서는 DPC / ISR, 드라이버, page fault, 열, 클록 변동 으로 흔들릴 수 있습니다. 이 단계가 되면 ETW / WPR / WPA나 LatencyMon으로 분리하면 원인이 보이기 쉬워집니다.

5. 전원 설정·OS 설정 체크리스트

평범한 Windows에서 잘 먹히는 설정은 먼저 Windows 표준 범위에 있습니다. 처음부터 BIOS / UEFI로 가기보다 다음 순서로 보는 편이 재현성이 좋습니다.

flowchart LR
    a["AC 전원과 전원 모드 확인"] --> b["필요하면 전용 전원 플랜 작성"]
    b --> c["power throttling과 timer 관련 확인"]
    c --> d["백그라운드 부하 줄이기"]
    d --> e["필요해진 뒤에야 BIOS / UEFI를 본다"]

체크리스트로는 다음과 같습니다.

1. AC 전원으로 구동 배터리 구동으로 맞춰도 결과가 안정되기 어렵습니다.

2. [설정] > [시스템] > [전원 및 배터리]의 전원 모드 확인 본번이나 계측에서는 [최상의 성능] 쪽을 쓰는 편이 자연스럽습니다.

3. 필요하면 전용 전원 플랜을 준비 평소용은 균형, 본번·계측만 전용 플랜, 이런 구분이 실무에서 다루기 좋습니다.

4. 최소의 프로세서 상태 / 최대의 프로세서 상태를 확인 전용기나 계측 시라면 AC 시만 100% / 100%를 시도해 볼 가치가 있습니다. 단, 열, 소비 전력, 팬 소음은 늘어납니다.

5. process power throttling / EcoQoS 확인 절전 쪽 설정이 들어가 있으면 짧은 대기나 실행 속도에 영향이 갈 수 있습니다.

6. 불필요한 백그라운드 부하 줄이기 클라우드 동기화, 자동 업데이트, 무거운 브라우저, 상주 모니터링, 인덱스 작성 등은 보통 영향을 줍니다.

7. 최소화 시나 비표시 시도 시험 Windows 11에서는 보이지 않는 상태의 앱에서 timer resolution 거동이 바뀔 수 있습니다.

8. BIOS / UEFI는 마지막에 본다 C-state나 벤더 고유의 정음 / Eco 설정이 먹힐 수는 있지만 기종 의존이 강합니다. Windows 쪽에서 다듬은 뒤 건드리는 편이 명료합니다.

6. 계측과 평가

6.1. 무엇을 기록할까

최소한 다음은 기록하고 싶습니다.

• 주기 예정 시각
• 실제 시작 시각
• 실제 종료 시각
• lateness
• 실행 시간
• missed deadline 수
• 연속 missed deadline 수
• queue 깊이
• 드롭 수
• DPC / ISR 스파이크
• page fault
• 온도 / 클록 변동

평균값만으로는 본번에서 곤란한 종류의 지연이 보이기 어렵습니다. 평범한 Windows에서 문제가 되는 건 평균으로는 빠르지만 가끔 크게 늦는다 는 형태이기 때문입니다.

6.2. p99 / p99.9 / max란 무엇인가

이 근방 용어는 처음에 의미를 잡아두면 명료합니다.

• 평균 전체의 중간 경향을 보는 지표입니다. 단, 가끔 나오는 큰 지연은 묻히기 쉽습니다.

• p99 전체 샘플의 99%가 이 값 이하 인 경계값입니다. 1000회 측정했다면 느린 쪽 10회를 제외한 상한에 가까운 값 이라고 생각하면 명료합니다.

• p99.9 전체 샘플의 99.9%가 이 값 이하 인 경계입니다. 1000회 측정했다면 느린 쪽 1회를 제외한 상한에 가까운 값 입니다.

• max 제일 나빴던 1회의 값입니다.

flowchart LR
    sample["1000회분 지연 수집"] --> sort["작은 순으로 정렬"]
    sort --> p99["p99: 990번째 부근"]
    sort --> p999["p99.9: 999번째 부근"]
    sort --> max["max: 1000번째"]

실무에서는 평균뿐 아니라 p99 / p99.9 / max 를 보는 편이 체감에 가깝습니다. 「평소엔 괜찮은데 가끔 걸린다」를 숫자로 보기에 이 시각이 편리합니다.

주의점으로, p99.9를 보려면 샘플 수도 필요합니다. 10Hz 처리로 1000 샘플 모으는 데만 100초가 걸립니다. 샘플이 적은 채 p99.9를 보면 우연한 1회에 강하게 끌려다닙니다.

6.3. 무엇으로 볼까

도구로는 대략 다음입니다.

• 앱 내 계측 먼저 자체로 period, lateness, execution time, queue depth를 취득

• ETW / WPR / WPA CPU, context switch, DPC / ISR, page fault를 본다

• LatencyMon 드라이버 기인 흔들림을 겨냥

• 온도 / 클록 감시 열이나 써멀 스로틀링 영향을 본다

먼저 앱 내 계측으로 내 처리가 무거운지, 외부에서 막혀 있는지를 분리합니다. 그 위에 ETW / WPR / WPA를 쓰면 DPC / ISR이나 page fault의 영향을 추적하기 쉬워집니다.

6.4. 테스트 조건

테스트는 조용한 개발기만으로는 부족합니다. 적어도 다음은 나눠서 보고 싶습니다.

• 기동 직후 워밍업 전
• 워밍업 후
• 장시간 연속 가동
• UI 전면
• UI 최소화 / 비표시에 가까운 상태
• AC 전원
• 배터리 구동
• 네트워크나 디스크 부하가 있는 상태

실운영에 가까운 조건에서 보지 않으면 나중에 「개발기에선 괜찮았는데」가 일어나기 쉬워집니다.

7. 대략적인 구분

평범한 Windows에서의 현실적 기준은 대략 다음처럼 생각하면 정리하기 쉽습니다.

• 10~20ms급, 가끔의 흔들림은 흡수 가능 fast / slow 분리, 고정 길이 큐, 일반~약간 높은 우선순위, 이벤트 구동으로 충분한 경우가 많습니다.

• 1~5ms급, 지속적으로 맞추고 싶다 fast path의 무할당화, 전용 스레드, MMCSS 또는 신중한 우선순위 조정, 고정밀 waitable timer, AC 전원, 최상의 성능 쪽 전원 설정을 세트로 봅니다.

• 1ms 미만에 가깝고, 장시간·고부하에서도 놓치고 싶지 않다 평범한 Windows의 user-mode 앱 단독으로는 버거워집니다. 크리티컬한 부분을 다른 곳으로 대피시키는 설계를 생각하는 편이 좋습니다.

• GUI, 로그, 통신, DB를 전부 동거시키고 싶다 1프로세스 1루프로 끌어안지 말고 책무를 분리하는 편이 안정적입니다. 후단 사정이 전단 기한을 깨기 쉬워지기 때문입니다.

8. 정리

평범한 Windows에서 소프트 리얼타임을 노릴 때 먼저 볼 것은 다음입니다.

1. 주기 루프가 Sleep 의존으로 되어 있지 않은지
2. fast path와 slow path가 나뉘어 있는지
3. 큐가 고정 길이이고 넘쳤을 때의 방침이 정해져 있는지
4. fast path에 I/O, 할당, 무거운 락이 들어 있지 않은지
5. 우선순위나 MMCSS를 필요한 스레드만 쓰고 있는지
6. 평범한 Windows의 전원 설정과 계측을 갖추고 있는지

평범한 Windows에서는 우선순위만으로 안정되는 일은 별로 없습니다. 설계, 대기 방법, 전원 설정, 계측을 갖춰야 비로소 덜 늦어지는 형태가 됩니다.

거꾸로 말하면 이 순서로 정리하면 평범한 Windows라도 soft real-time으로서 꽤 실용적인 곳까지 데려갈 수 있습니다.

9. 참고 자료

• Multimedia Class Scheduler Service
• AvSetMmThreadCharacteristicsW function
• SetThreadPriority function
• SetPriorityClass function
• timeBeginPeriod function
• CreateWaitableTimerExW function
• Acquiring high-resolution time stamps
• GetSystemTimePreciseAsFileTime function
• SetProcessInformation function
• VirtualLock function
• CPU Sets
• SetThreadIdealProcessor function
• SetThreadAffinityMask function
• Processor power management options
• Windows PC의 전원 모드 변경하기
• CPU 분석 (WPA / WPT)
• Stopwatch Class