몇달전에 컴퓨터가 버벅거리거나, 노래를 틀어놓으면 두두두거려서 참 거슬렸었습니다.
음악이야 WASAPI를 이용하면 해결가능했으나. (꼭 단독모드가 필요하진 않음)
유투브등의 플래쉬플레이어,게임등에서 두두두 거리는건 참기 힘들더군요.
이런 문제가 있을땐 지금까지 일반적으로 알려진 분석책은 DPC Latency Checker를 이용해
시스템에 문제가 있나 없나 확인하는 정도에 그치는 것이 컴퓨터에 깊게 알지못하는 저같은 일반인의
방법이었습니다. DPC Latency Checker는 아래 주소에서 받으실수 있습니다.
▶ Thesycons DPC Latency Checker
내용보기 : http://parkoz.com/v_agzi
예를 들자면 문제가 없는 시스템은 아래와 같이 녹색줄로 표현되고
문제가 있는 시스템은 빨간줄 노란줄이 중간중간 나타나죠.
위 툴의 맹점은 문제가 존재하는지만 분석이 가능하고 어느 장치가 문제의 발생원인지는
제시해주지 못합니다.
이경우 장치 하나하나를 분해 조립 해가면서 원인을 찾기 마련인데....
최근 검색해보니 DPC latency의 빨간줄의 범인을 쉽게 밝혀줄만한 툴이 있었더군요!
바로 LatencyMon이라는 프로그램입니다.
XP에서 안됀다는 말씀이 있으셔서 제품 페이지 보니 XP는 공식지원에서 빠져있습니다. (제가 제대로 확인을 안했군요 죄송합니다.)
아래의 주소에서 받을수 있습니다.
http://www.resplendence.com/download/LatencyMon.exe
아래의 주소는 제품 설명 페이지입니다. 영어 잘보시는 분들은 직접 보시면 됩니다.
http://www.resplendence.com/latencymon
다운후 설치해주시고, 실행시키면 아래와 같은 스크린이 나타납니다.
1.모니터링 시작.
묻지도 따지지도 말고 클릭! 을 하면 DPC Latency Checker처럼 모니터링을
시작합니다.
2.문제있는 장치 찾아내기
버튼을 누르자마자 가장 DPC실행시간이 긴 장치를 표시해 줍니다.
일단은 500ц이상의 실행시간이 과다하게 많다면 의심해봐야 합니다.
3.다른 장치의 상태도 보고싶다!
다른 장치도 문제가 있을지 모르고, 상태를 알고 싶다면 Drivers 탭을 클릭합니다.
Drivers를 클릭하게되면 다음과 같은 화면이 나오게됩니다.
두번 클릭하게되면 아래와 같이 가장 높은 실행시간을 갖게되는 드라이버가 순차적으로 표시됩니다.
여기서 0.5ms 이상의 실행시간을 갖는 드라이버와 연관된 장치 위주로 점검 해보시면 문제 해결이
쉬워집니다.
저같은 경우는 VGA 드라이버가 1ms(1000цs)~10ms(10000цs)을 수시로 넘나들었고
VGA 탈착과 슬롯 청소로 원만하게 해결할수 있었습니다.
제 경험으로 작성하게 된것이지만 이상증상의 스크린샷은 재현하기 힘들어서
구글 검색으로 갖다 붙인 이미지입니다. 양해 부탁드립니다.
참고로 Latencymon에는 정확한 측정을 위해 AMD의 CnQ(쿨콰)나 Intel의 EIST를 끄고 테스트하라는 첨언이 있습니다. DPC(Deffered Procedure Call)의 실행 시간을 측정하기 때문에, CPU클럭이 변화하면 DPC실행시간에 편차가 생기기 때문입니다.
노트북과 같은 CPU클럭이 지나치게 낮아지는 시스템의 경우 DPC실행시간이 지나치게 높을수 있으니 정확한
테스트를 위해 EIST와 CNQ를 끄고 진행해주시기 바랍니다.
김현성님 말씀 감사합니다. (--) (_ _) ^^;;
XP쓰시는 분들은 RATTv3이용하시면됩니다. 대신 UI없이 텍스트 파일로 로그 분석을 해야하는 단점이 있습니다.
http://msdn.microsoft.com/en-us/windows/hardware/gg487354
로그는 Windows\system32\Logfiles\Rattv3에
있다고 합니다.
저도 로그를 찾지 못해 RATTv3사용을 포기했었는데..
이승준님 말씀 감사합니다.^^;;;;
#####################
본 글은 주식회사 심스뮤직(http://www.simsaudio.co.kr)에서 가져온 글입니다.
DPC Latency Checker 프로그램 다운로드!! 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를 다운받아서 실행시키면 끝입니다. 실행 화면은 다음과 같습니다.
Analysing drou-out problems with DPC Latency Checker어떤 드라이버가 과도한 DPC 레이턴시를 발생시키는지 윈도우 장치 관리자에서 각 장치를 한 번에 하나씩 사용하지 않도록 처리하면서 찾아볼 수 있습니다.
장치 하나를 사용하지 않도록 한 뒤, DPC 레이턴시 체커의 그래프를 주의깊게 살펴보세요. 과도한 레이턴시 (빨간 기둥) 이 사라졌다면 문제의 원인이 되는 장치 드라이버를 찾은 것입니다. 아직 빨간 기둥이 그대로라면 또 다른 드라이버에 대해 반복합니다. 많은 경우 DPC 레이턴시는 아래와 같은 드라이버에서 많이 발생하니 이것들을 먼저 체크해 보세요.
문제가 되는 장치 드라이버를 찾았으면 해당 장치 판매자의 웹사이트에서 드라이버를 업데이트받으세요. 여의치 않다면, 실시간 데이터 처리 프로그램을 사용할 때는 해당 장치를 사용하지 마시기 바랍니다. 위와 같은 방법으로도 어디가 문제인지 알 수 없을 경우에는 마이크로소프트에서 제공하는 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가 지연되어 실행되지 못한 상태에서 다음번 인터럽트가 발생하면, 보통 하드웨어 버퍼 오버런이 발생하고, 데이터의 흐름이 끊깁니다. 따라서 드롭아웃이 발생합니다. [출처] DPC LATENCY CHECKER (DPC 레이턴시 체커)|작성자 또해봐 |
####################
![[레벨:60]](http://www.teambh.net/modules/point/icons/bhrank2/60.gif "포인트:54480point (26%), 레벨:60/230"){kind=icon}
드로이얀7(이준호)※ x86이 32bit용이고 x64는 64bit용입니다.
pci latency tool을 소개합니다.
http://www.parkoz.com/zboard/view.php?id=my_tips&no=9387
PCI 버스의 동작 원리.
http://www.parkoz.com/zboard/view.php?id=my_tips&no=7886
실제 PCI 레이턴시로 인해 문제가 생긴 사례
http://www.teambh.net/bbs/board.php?bo_table=tbh_hwqna&wr_id=10832
일반적으로 PCI버스는 전체 공유방식입니다. 일반적으로 PCI는 32bit*32Mhz=133MB/s인데, PCI 슬롯이 6개 있으면 총 대역폭은 133MB/s * 6 = 798MB/s가 아니라 그냥 133MB/s입니다.
길 하나를 여럿이서 공유해서 쓰니깐 사용순서를 잘 정해야 문제가 없겠죠. 이걸 정하는 규칙중 하나가 PCI latency 입니다.
PCI latency 는 해당 장치가 PCI버스를 얼마나 오랫동안 붙들고 있을 수 있느냐를 정합니다. 예를들어 사운드카드와 IDE(하드디스크)가 PCI에 물려 있다고 칩시다. 그리고 사운드카드가 동작중에 하드디스크가 사용요청을 해왔다면(우선권 얘기는 편의상 생략) 사운드카드는 PCI 버스 사용을 중지해야 겠죠. 이때 PCI latency 가 0이라면 즉각중지하겠지만 128로 되있지만 128만큼 PCI버스를 더 붙들고 있다가 내주겠죠.
대부분의 경우에는 문제가 없습니다만 가끔 문제가 생기는 경우도 있습니다. 위의 경우 하드디스크 사용중에 사운드카드가 사용요청을 해왔는데 IDE PCI latency 248씩이나 잡혀있다고 치면 하드디스크가 그만큼 오랫동안 PCI 붙들고 앉아있다가 늦게 내주니깐 소리가 끊기거나 하게 되겠죠.
많은 메인보드가 기본적인 PCI latency 조절을 지원합니다만 PCI latency tool은 각 장치별로 따로 레이턴시를 조절할 수 있습니다.
문제가 있으신 분은 맨 위에 소개글 보고 한번 조절해 보세요.
덧 : 저걸 써보시면 아시겠지만 아주 구형 보드가 아니어도 의외로 PCI에 여러장치를 물려놓은 경우가 많네요. 현재 아버지 컴에 있는 Abit KV8 Pro만 해도 애슬론64 및 HT(하이퍼트랜스포트) 지원 메인보드임에도 불구하고 PCI latency tool로 보면 무려 16개 장치가 나오며 특히 USB랑 IDE슬롯을 전부다 PCI에 물려놓은게 매우 실망스럽네요.
아마 기존에 쓰던 PCI가 설계하기 쉬우니깐 저렇게 해놓은 모양인데, PCI는 지금 시점에선 구세대 슬롯입니다. 당연히 HT나 PCIE에 물리는 것보단 레이턴시나 대역폭에서 불리합니다 - 성능이 떨어지지요.
최근 nForce칩셋의 경우 하이엔드 제품에서 SATA2를 PCI에 물려놓는 뻘짓을 한것으로 추정되어 욕 먹기도 했죠.
SATA2를 PCI에 물려놓으면 제 아무리 20만원짜리 10000RPM 랩터 150G를 4개 레이드 해놔도 PCI대역폭인 133M - 그것도 이론상 한계고 실제로는 약 100~120M - 에 묶일 뿐더러 PCI에 물려있는 다른 장치들은 IDE사용중엔 PCI대역폭을 거의 못 쓰므로 전반적인 성능저하를 일으킵니다.
nForce4 - 소켓 939 시절에도 nForce에서 SIS나 ATI메인보드로 갈아탄 분들 대부분이 체감성능이 상당히 향상되었다고 했죠.
관련 벤치마크 링크 겁니다. 궁금하신 분은 직접 가서 한번 보세요.
http://www.parkoz.com/zboard/view.php?id=int_news&no=8836