이 문서는 THESYCON 사의 DPC Latency Checker 프로그램 설명 문서에 대한 liquidbird(http://liquidbird.springnote.com/pages/2773086) 님의 번역입니다.

원본 설명 문서 PDF 및 DPC Latency Checker 프로그램을 다운받을 수 있는 곳은 다음과 같습니다.

http://www.thesycon.de/eng/free_download.shtml

THESYCON Systemsoftware & Consulting GmbH

DPC Latency Checker

Thesycon's DPC 레이턴시 체커는 컴퓨터 시스템이 실시간 데이터 스트림을 어느 선까지 제대로 처리할 수 있는지를 분석하는 윈도우 툴입니다. 이 툴을 사용하면 실시간 오디오/비디오 데이터 스트림에 발생하는 인터럽트 - 보통 '드롭아웃 (dropout)' 이라고 불리는 현상 - 의 원인을 찾는 데 도움이 됩니다. 이 프로그램은 윈도우 2000, XP, XP x64에서 작동합니다.

The DPC Latency Checker Tool

윈도우 시스템상의 어떤 커널모드 장치 드라이버 프로그램이 올바르게 만들어져 있지 않으면 Deferred Procedure Calls (DPCs) (지연 처리 호출) 수행시 매우 큰 레이턴시가 발생하고, 이는 실시간 오디오 및 비디오 스트림을 사용하는 프로그램에서의 드롭아웃 현상으로 이어집니다. 이에 대한 보다 자세한 설명은 뒤에 나오는 배경지식 부분을 참고하세요.

DPC 레이턴시 체커 툴을 통해 윈도우 시스템에서 발생하는 DPC 레이턴시의 최대값을 찾아서, 그 컴퓨터의 실시간 처리 능력을 파악할 수 있습니다. DPC 레이턴시 체커는 어떤 외부 하드웨어와도 독립적으로 작동합니다. 이 툴은 다음과 같은 상황에 유용합니다.

• 오디오/비디오와 같은 실시간 데이터 처리시 인터럽트(드롭아웃)이 발생하는데 원인을 찾고 싶은 경우
  
• 윈도우 시스템이 올바르게 설정되어서 실시간 데이터를 제대로 처리할 준비가 되었는지, 스트림 데이터 처리 프로그램들을 설치하기 전에 알고 싶을 때
  
• 특정 컴퓨터 시스템이 실시간 데이터 처리에 적합한지 알고 싶을 때. 예를 들어 컴퓨터를 사기 전에 미리 알아볼 수 있습니다.

Using DPC Latency Checker

사용법은 매우 간단합니다. dpclat.exe를 다운받아서 실행시키면 끝입니다. 실행 화면은 다음과 같습니다.

DPC 레이턴시 체커는 주기적 - 실행화면에 Test Interval 로 표시되는 값 - 으로 내부 통계데이터를 갱신하여 매 초마다 화면에 표시합니다. 현재 레이턴시 값 - 실행화면의 'Current Latency' - 은 마지막 1초 동안 측정된 최대 DPC 값입니다. 'Absolute Maximum' (절대 최대치)는 이 프로그램이 실행된 이래의 최대값을 표시합니다. 리셋 버튼을 누르면 이 값은 초기화됩니다.

[....뻔한 이야기는 생략...]

아래 그림은 흔한 문제 유형의 예입니다. 과도한 DPC 레이턴시가 빨간 기둥으로 표시됩니다.

매 3초마다 시스템의 커널모드 드라이버가 CPU를 약 3.5 밀리세컨드 (그래프 범례를 보면 3500 마이크로세컨드 = 3.5 밀리세컨드 ) 씩 장악하고 있습니다. 따라서 매 3초마다 DPC 레이턴시가 비정상적으로 크게 되고 실시간 데이터 스트림에서 드롭아웃이 발생합니다.

Analysing drou-out problems with DPC Latency Checker

어떤 드라이버가 과도한 DPC 레이턴시를 발생시키는지 윈도우 장치 관리자에서 각 장치를 한 번에 하나씩 사용하지 않도록 처리하면서 찾아볼 수 있습니다.

장치 하나를 사용하지 않도록 한 뒤, DPC 레이턴시 체커의 그래프를 주의깊게 살펴보세요. 과도한 레이턴시 (빨간 기둥) 이 사라졌다면 문제의 원인이 되는 장치 드라이버를 찾은 것입니다. 아직 빨간 기둥이 그대로라면 또 다른 드라이버에 대해 반복합니다.

많은 경우 DPC 레이턴시는 아래와 같은 드라이버에서 많이 발생하니 이것들을 먼저 체크해 보세요.

• 네트워크 어댑터 (유선, 무선)
  
• 내장형 모뎀
  
• 내장형 사운드 장치 (온보드 사운드)
  
• PCI / PCI Express 카드, PCCard / ExpressCard. 예를 들어 TV 튜너 카드, ISDN/DSL 어댑터, 모뎀 등

주의 : 다음 드라이버는 컴퓨터 작동에 꼭 필요하니 중지시키면 안 됩니다.

• '시스템 장치' 항목의 장치들
  
• 하드디스크
  
• 하드디스크에 대한 IDE/ATAPI, SATA 컨트롤러
  
• 키보드
  
• 마우스, 트랙포인트, 터치패드
  
• 키보드/마우스가 연결된 USB 컨트롤러
  
• 디스플레이 컨트롤러

문제가 되는 장치 드라이버를 찾았으면 해당 장치 판매자의 웹사이트에서 드라이버를 업데이트받으세요. 여의치 않다면, 실시간 데이터 처리 프로그램을 사용할 때는 해당 장치를 사용하지 마시기 바랍니다.

위와 같은 방법으로도 어디가 문제인지 알 수 없을 경우에는 마이크로소프트에서 제공하는 RATT 툴을 사용해서 체크해볼 수 있습니다. 하지만 RATT는 사용하기 어렵고, RATT가 만들어낸 분석결과는 알아보기가 힘듭니다. RATT를 다운로드받으려면 구글에서 'Microsoft RATTV3'를 검색하면 됩니다.

배경지식 : 드롭아웃은 왜 발생하는가

윈도우 기반의 응용프로그램과 장치 드라이버를 통해 실시간 데이터 스트림을 처리하는 것은 굉장히 어렵습니다. 왜냐하면 윈도우 자체가 실시간 운영환경이 아니기 때문입니다. 윈도우에서는 어떤 (주기적인) 동작이 정확한 타이밍에 실행된다는 보장이 전혀 없습니다.

외부 장치로 나가거나 외부 장치에서 들어오는 오디오/비디오 스트림은 커널모드 장치 드라이버에서 처리하는데, 처리 방식은 실시간이 아니라 인터럽트 기반 (interrupt-driven) 방식입니다. 보통 외부 하드웨어는 주기적으로 인터럽트를 발생시켜서, 장치 관리자가 해당 하드웨어로 (또는 해당 하드웨어로부터) 다음번 데이터 블록을 전송하도록 합니다. 윈도우 NT 기반 시스템 (윈도우 2000 이상. XP도 NT기반입니다.) 에서는 고유의 인터럽트 핸들링 매커니즘이 있습니다. 장치 관리자는 원하는 순간에 데이터를 즉시 처리할 수 없고, Deferred Procedure Call (DPC : 지연 처리 호출) 스케쥴에 처리할 작업을 등록하면, OS에서 이 스케쥴에 따라 최대한 빨리 장치 관리자를 다시 호출하여 작업을 수행하게 됩니다. (callback routine)

OS는 각 장치 관리자들로부터 받은 DPC 요청을 큐(queue)에 넣어서 관리합니다. CPU 하나당 DPC 큐 하나가 있습니다. 어떤 순간에, 윈도우 커널은 DPC 큐를 체크하여 현재 처리해야 할 인터럽트가 없고 현재 실행중인 DPC 요청도 없다면, DPC 큐에 쌓인 DPC요청들 중 첫번째 요청을 큐에서 꺼내어 이를 실행시킵니다. DPC 큐 처리는 dispatcher가 스레드를 선택하여 이를 CPU에 할당하기 전에 이루어지므로, DPC는 시스템에서 다른 어떤 스레드보다 우선 처리됩니다.

DPC 개념은 커널모드에서만 존재합니다. 유저 모드 코드 (윈도우 응용프로그램) 는 스레드 컨텍스트에서 실행됩니다. 스레드들은 디스패처에 의해 관리되고 실행됩니다.

DPC에 의한 작업은 스레드들보다 우선권이 있지만, DPC가 여러 개 있을 경우 각각의 DPC는 DPC 큐의 선입선출 방식에 의해 순차적으로 실행됩니다. 따라서 DPC간의 협조적인 멀티태스킹 체계가 존재합니다. 만약 어떤 DPC가 과도한 시간동안 실행되면, 다른 DPC들은 그 시간만큼 지연됩니다. 결과적으로, 특정 DPC의 레이턴시라는 것은, DPC 큐 상에서 그 DPC보다 먼저 실행되도록 되어 있는 (앞에 쌓여 있는) 다른 DPC들의 실행시간을 모두 합친 것과 같습니다. 만족할 만한 DPC 레이턴시를 달성하기 위해, 윈도우 장치 드라이버 킷 (DDK) 문서에서 마이크로소프트는 DPC루틴에서 가능한 한 빨리 복귀할 것을 권고하고 있습니다.  긴 시간이 걸리는 작업이나, 하드웨어 상태가 바뀌길 기다리면서 반복해서 수행하는 작업(polling)은 사용하지 말라고 강력하게 이야기합니다.

불행히도 많은 장치 드라이버 프로그램은 이런 조언에 따르지 않았습니다. 어떤 드라이버들은 DPC 루틴에서 과도한 시간을 차지하여, 다른 DPC들에 비해 엄청나게 큰 레이턴시를 발생시킵니다. 데이터 스트림을 실시간으로 처리하는 장치 관리자에서는, 하드웨어가 다음번 인터럽트를 발생시키기 전에 DPC작업이 수행되어야 하는 것이 결정적입니다. 만약 DPC가 지연되어 실행되지 못한 상태에서 다음번 인터럽트가 발생하면, 보통 하드웨어 버퍼 오버런이 발생하고, 데이터의 흐름이 끊깁니다. 따라서 드롭아웃이 발생합니다.