파티션을 나누거나, 포맷을 할 때면 실수로 파티션 테이블을 지우거나 바꿀 때도 있다. 파티션 삭제를 파일 삭제와 비슷한 사고라고 생각하고 파일 복구 방법을 찾는 경우가 많다. 하지만 실상은 파티션 복구만 해낸다면 모든 파일을 제자리로 돌릴 수 있다. 심지어 파티션 복구는 파일 복구보다 쉽고, 빠르고, 복원 가능성도 높다.
파티션이란?
우선 파티션의 구조 먼저 이해해야 한다. 일반적으로 MBR(Master Boot Record)에 있는 파티션 테이블에 파티션 정보를 기록한다.
파일 하나를 찾을 때, MBR의 파티션 테이블에서 파티션의 위치를 찾고 그 위치에 가서 파티션 구간 내부의 구조를 확인한다(흔히 포맷이라고 하는 NTFS, APFS, EXT4등이 그 구조에 대한 정보를 담고 있다). 이 구조에 있는, 파일 구조가 명세 된 파일에서 파일의 위치를 찾아 파일을 불러오는 것이다.
요즘은 MBR 대신 GPT를 쓰는데, 그 곳에 파티션 테이블이 포함되어 있다. 결론은, 파티션을 아무리 지우고 수정해도 파일이 저장되는 부분과는 독립적인 공간이고, 파일이 저장되는 부분은 건드리지 않는다는 것이다.
파티션과 파티션 포맷
보통 파티션을 변경하면 파티션 포맷도 같이 하기 때문에 파티션과 파티션 포맷을 연결해서 생각하기 쉽다. 하지만 파티션과 파티션 포맷은 엄연히 다른 것이다.
포맷은 틀을 잡는 것이다. 파티션 된 공간 안에서 데이터를 기록할 수 있도록 틀을 구성한다. 파일 구조가 명세 된 파일을 지우고 다시 구축한다. 포맷에 따라 파일 명세가 달라지기 때문에 필수적이다.
파티션은 저장 장치에 가장의 벽을 설치하기 위해 파티션 테이블을 수정한다. 파티션 포맷이나 파일 구조를 수정하지 않는다. 파티션 테이블에 포맷 정보가 담겨있기 때문에 파티션을 수정하면 파티션의 포맷이나 파일 구조를 읽어 올 수 없다. 파티션 테이블을 변경하면 포맷 정보를 읽어 올 수 없게 되므로 일반적으로는 파티션을 변경하면 포맷도 한번에 수행한다.
현실로 비유하자면, 파티션은 가벽 파티션을 생각하면 되고, 포맷은 책상을 생각하면 된다.
파티션을 만들더라도 책상이 없으면 물건을 놓을 수 없다.
공간이 좁아지도록 파티션을 옮기면 책상이 잘려서 책상을 사용할 수 없다.
공간이 넓어지도록 파티션을 옮기더라도, 책상을 새로 들이지 않으면 물건을 올려 둘 수 있는 공간은 그대로다.
이런 구조이기 때문에, 파티션 테이블을 완전히 삭제한 후 재구축 한 상태라도 파티션 테이블을 복구할 수 있다면 모든 파일이 그대로 남아있게 된다!
앞에 언급한 것처럼 대부분의 소프트웨어들은 파티션을 변경하면 포맷도 같이 진행한다. 그래서 파티션을 관리하는 특수한 소프트웨어를 사용해야 한다. 그 특수한 소프트웨어를 이용해 파티션을 복구해보자.
MiniTool Partition Wizard 9.0
대표적으로 MiniTool Partition Wizard가 있다. 현재 13.5 버전까지 출시되었지만, 파티션 복구 기능을 무료로 사용할 수 있는 버전은 MiniTool Partition Wizard 9.0이다.
복구 방법 설명을 위해 방금 만든 가상 HDD에 파일 하나만 저장한 후 다시 파티션을 삭제했다.
비밀번호 kollhong.com 공식 사이트가 아닌 곳에서 다운로드 할 때는 반드시 checksum 확인, 서명 확인!!
실행
Partition Recovery Wizard 실행
파티션 관리 도구에 파티션 복구 기능도 제공되는 것이어서 파티션 복구 위자드를 실행해야 한다.
왼쪽 Wizards 메뉴에서 Partition Recovery Wizard 실행
다음 클릭
복구 할 디스크 선택
스캔 범위 선택. 실수로 파티션을 삭제한 후 다시 파티션을 만든 게 아니라면 Unallocated Space로 충분하다.
스캔 방식 선택. 마찬가지로 실수로 파티션을 지운 후 다시 파티션을 만들지 않았다면 Quick Scan을 선택하면 된다.
그러면 위와 같이 검색 된 파티션이 보인다. 남겨 둘 파티션을 선택하는 것이므로 현재 HDD에 남아있는 파티션도 선택해야 한다.
왼쪽 상단의 Apply 버튼을 누른다.
진행 후 위와 같은 창이 뜨면 성공
드라이브 레터 지정
파티션을 복구하더라도 Windows 탐색기에는 복구 한 파티션이 보이지 않을 수 있다. 파티션은 존재하지만 파티션에 드라이브 레터가 존재하지 않아서 마운트 되지 않은 것이다.
'하드 디스크 파티션 만들기 및 포맷' 실행
복구 한 파티션 선택, 우클릭, 드라이브 문자 및 경로 변경
추가 클릭
원하는 드라이브 문자 할당. 보통 C부터 순서대로 할당되므로 특별한 경우가 아니면 바로 '확인'을 클릭하여 저장하면 된다.
복구를 성공적으로 완료하면 기존의 파일까지 전부 보인다.
번외 - 파일 복구 프로그램
같은 업체에서 제공하는 파일 복구 프로그램이다. 파티션 복구와 달리 파티션이 있던 구간 전체를 스캔해야 하므로 시간이 오래 걸린다.
다행히 지워진 파일을 찾았다. 하지만 파일 이름을 인식하지 못한다. 뿐만 아니라 확장자 또한 html이 아닌 htm으로 되어 있다. 파일 내용에 따라 형식을 추론하기 때문이다. 파일 구조 가 명세 된 파일은 포맷에 관련 되어 있기 때문에 포맷을 복구하는 프로그램이 아니라면 인식하기 어렵다.
UEFI 바이오스에서 윈도 설치 디스크 만들기가 굉장히 쉬워졌다. 그러나 여전히 rufus와 같은 유틸리티를 사용하여 복잡하게 만드는 것이 일반적이다.
이 글에서는 다른 프로그램 없이 바로 부팅 가능한 윈도 설치 USB를 만들어보기로 한다. 방법이 굉장히 간단하기 때문에 본문도 굉장히 짧다.
그래서 서론으로 UEFI는 어떤 특징이 있는지 알아보고, 윈도 설치 ISO를 다운로드하는 방법을 알아본다.
그리고 본문으로 UEFI의 특징을 살려 윈도우 설치 디스크를 만드는 방법을 알아보고자 한다.
UEFI
UEFI의 가장 큰 특징은 기존의 BIOS 시스템에 비해 더 큰 시스템이라는 것이다.
옛날의 BIOS는 기본적인 설정과, POST(Power On Self Test)기능만 제공한다.
하지만 UEFI는 좀 더 많은 기능을 제공한다. 기본 설정과 POST 뿐 아니라, 커서 기능, GUI기능, 빠른 부팅, CLI를 제공한다. 빠른 부팅은 POST 결과를 저장해서 다음에는 POST 단계를 줄이는 기능이다. CLI는 BIOS 단계에서 명령을 실행할 수 있는 환경을 제공한다는 의미이다.
여기서 중요한 게 CLI이다. CLI로 명령을 실행하려면 BIOS가 외부 저장장치에 엑세스 할 수 있어야 한다. UEFI가 외부 저장장치에 엑세스 할 수 있다는 또 다른 증거가 있다. UEFI는 설정 화면의 스크린샷을 연결된 USB 메모리에 저장할 수 있다는 것이다..
그리고 이런 기능의 지원을 위해 UEFI 바이오스는 FAT32 포맷의 외부 저장장치에 접근할 수 있다.
위와 같은 사이트가 나타난다. 우리는 컴퓨터를 업데이트 할 것이 아니라, ISO를 만들 것이기 때문에 '지금 도구 다운로드'를 클릭한다. 'MediaCreationTool'이 다운로드 된다.
약관을 반드시 읽어보아야 한다.
프로그램을 실행하고 프로그램 사용권을 자세히 읽은 후 동의한다면 동의 버튼을 눌러 진행한다.
공식 문서이든, 블로그 문서이든, 수많은 튜토리얼을 보면 대부분 게시물들이 위와 같은 약관이나 사용 조건에 대한 동의 화면이 나오면 무조건 동의 버튼을 누르라고 하고 있다. 물론 대부분의 약관은 사용자를 방해하거나 목을 조르려는 용도로 만들지는 않지만, 반드시 읽어보도록 안내 해주었으면 하는 바람이 있다. 이 약관은, 프로그램 제조사와 사용자 사이의 법적으로 유효한 '계약'이며, 소비자의 보호, 제조사의 보호 또는 분쟁시 분쟁 중재를 위한 내용이다.
다운로드 과정
'다른 PC용 설치 미디어 만들기' 를 클릭하고 다음을 누른다.
다운로드 과정
어와 아키텍처를 선택하고 다음을 누른다. 에디션은 통합본으로 나오기 때문에 한 종류 뿐이다. 아키텍처는 Windows 8이나 그 이후 버전이 설치되어 출시된 컴퓨터라면 64비트를 선택하면 된다.
다운로드 과정
ISO 파일을 만들 것이기 때문에 'ISO 파일'을 선택하고 다음을 클릭한다.
USB 플래시 드라이브를 선택하더라도 FAT32로 포맷한다. 따라서 'USB 플래시 드라이브'를 선택하고 진행해도 결과는 같다. 단지 이 튜토리얼은 FAT32로 포맷하는 것이 얼마나 편리한지를 보여주기 위한 것이기 때문에 'ISO 파일'로 진행한다.
파일 위치 선택 대화상자가 나타나면 다운로드할 위치를 설정한다.
다운로드 중 다운로드 중
그러면 다운로드가 시작되고, 미디어를 만드는 작업을 한다.
다운로드 완료
ISO 만들기가 완료됐다. DVD 버너를 사용할 것이 아니기 때문에 '마침'을 눌러 종료한다.
코어파킹에 대한 포스트 제목이 "더 조용하게, 더 오래!"였지만 실제로 모바일이나 배터리에 관한 언급은 거의 없었습니다.
오히려 고성능 위주의 HEDT에 적절한 설정값을 공유하거나 추천해드렸습니다.
이번에는 모바일에 대하여 말해보려고 합니다. 클럭이 높을수록 에너지 효율이 떨어지기 때문에 클럭이 낮게 유지될 수 있어야 합니다. 단기적으로는 더 조용하고 오래 사용할 수 있습니다. 발열량이 감소하기 때문에 높은 성능이 필요한 순간에 높은 성능을 낼 수 있고, 장기적으로는 더 높은 성능까지 낼 수 있어야 합니다. 하지만 장기적으로 빠른 처리를 하기 위해 단기적인 관점에서 성능 하락이 크면 안될겁니다.
기존에 코어파킹 강좌에서 언급했거나 설명했던 항목들은 전체적인 부분을 조절하는 항목들입니다.
CPU의 사용량에 따라 설정한 가장 낮은 클럭부터 설정한 가장 높은 클럭 사이를 조절하는 항목이거나, CPU의 사용량에 따라 활성화 된 코어를 설정한 최솟값과 최댓값의 사이에서 조절하는 항목입니다.
이번에는 단순한 클럭 조절을 위한 코어 파킹 설정이 아닙니다. 부스트 클럭을 조절하기 위한 항목에 대해 언급하려고 합니다.
부스트 클럭과 TDP
CPU 제조사들은 코어를 늘리면서 발열을 해소하기 위해 Base Clock을 낮추고, 동시에 특수한 상황에서는 오히려 성능이 낮아지는 단점을 해소하기 위해 Boost Clock이라는 개념을 적용했습니다.
모바일은 TDP로 발열을 제어합니다. 데스크톱도 발열제어를 하지만 큰 영향을 받지는 않습니다.
TDP에 의한 발열 제어는 CPU만 고려합니다. 그러다보니 CPU의 성능은 남고 GPU의 성능은 부족한데 TDP제한이 작동하지 않았던 경우도 있습니다. 그래서 라이젠 모바일 프로세서의 경우는 TDP를 더 낮춰서(클럭이 더 낮게 유지됨) 더 높은 게이밍 퍼포먼스를 달성하기도 하였습니다. 인텔이든 AMD든 상관 없이 클럭이 높기 때문에 부스트 클럭을 제한함으로써 배터리와 발열은 개선하면서도 체감 차이는 거의 없는 후기가 올라오기도 하였습니다.
데스크톱 프로세서라고 예외는 아닙니다. TDP에 의한 발열 제어는 데스크톱 프로세서와는 관련이 없지만, 부스트 클럭의 조절이 필요합니다. Intel Core i9-9900K의 터보 클럭 스펙은 다음과 같습니다.
부스트 클럭으로 작동하는 코어가 많아질수록 최대 클럭은 낮아집니다. 만약 싱글 쓰레드 위주의 프로그램을 실행할 때 모든 코어가 부스트 클럭으로 유지되고 있다면 어떨까요? 해당 쓰레드는 실제로는 4.7Ghz처럼 처리되겠죠. 게다가 파일 탐색기나, 마우스 커서의 움직임처럼 간단한 작업을 처리하는 프로세스들도 불필요하게 4.7Ghz로 처리될겁니다. 하지만 부스트 클럭으로 작동하는 코어를ㄹ 잘 조절하면 높은 성능이 필요한 쓰레드는 5.0Ghz로 작동할 겁니다. 다른 코어에서 실행되는 프로세스들은 베이스 클럭인 3.6Ghz의 속도이지만 체감 차이 없이 처리될 수 있습니다.
코어 수가 많아지면서 베이스 클럭과 부스트 클럭의 차이가 커지는 양상을 보이고 있습니다. 또한 부스트 클럭으로 작동하는 코어의 수에 따라 부스트 클럭도 달라집니다. 클럭이 높을 수록 에너지 효율이 떨어지고 연산량 대비 발열량이 증가합니다. 그렇기 때문에 베이스 클럭은 낮추고, 부스트 클럭도 활성 코어 수에 따라 변하게 하는거죠.
베이스 클럭 자체도 낮은 성능은 아닙니다. 그렇기 때문에 베이스 클럭은 자주 사용되고 부스트 클럭은 덜 사용된다면 발열 제어에 여유가 생겨서 필요할 때에 높은 성능을 낼 수도 있고, 체감 성능 하락도 작아질 것입니다. 그렇기 때문에 부스트 클럭을 적절히 조절하면 높은 성능을 유지할 수 있습니다.
부스트 클럭 설정 조정
윈도우는 작업 관리자에 베이스클럭이 표시됩니다. 즉, 윈도우는 베이스 클럭과 부스트 클럭을 인식할 수 있다는 거죠.(물론 맥이나 리눅스도 마찬가지입니다)
그리고 윈도우는 부스트 클럭에 관한 조절 기능도 제공하고 있습니다. 하지만 기본값이 일반 베이스 클럭과 다를 바 없이 대하도록 되어 있습니다. 그렇기 때문에 웹 브라우저를 실행하고, 웹서핑하는 내내 높은 클럭이 유지됩니다.
반면 MacOS의 경우는 베이스클럭에 있는 시간이 부스트 클럭에 있는 시간보다 깁니다. 웹 브라우저를 실행할 때는 부스트 클럭으로 작동하지만, 웹서핑할 때는 베이스 클럭보다 높은 주파수로 올라가지 않습니다. 그러다가 링크를 클릭하여 다른 웹 페이지로 이동할 때는 부스트 클럭으로 작동합니다.
램 선택의 기준은 물론 '필요하냐 필요하지 않냐'가 기준입니다. 그런데, 그 필요성을 따지는 것을 단순한 체감으로 판단하기는 쉽지 않습니다. 왜냐하면 사용자가 컴퓨터를 업그레이드를 하기도 전에 업그레이드 된 컴퓨터의 속도를 알 수 없기 때문이죠. 그래서 보통은 현재 컴퓨터 리소스(RAM, CPU 등)의 사용량을 확인합니다. 하지만 컴퓨터의 운영을 고려해보면 단순히 리소스의 사용량을 확인하는 것은 확실성을 떨어트릴 수 있습니다. 이 글에서는 업그레이드에 좀 더 확실한 근거를 제시하려고 합니다. 특히 램을 중점적으로 다뤄보겠습니다.
이 글은 추가적인 램이 필요한지에 대한 객관적인 기준을 다루는 것이 아닙니다. 어차피 물컵에 물이 반이 남아 있어도 '반이나 남았네!'라고 생각하는 사람도 있고, '반 밖에 안남았구나..ㅠㅠ' 라고 생각하는 사람도 있으니까요. 하지만 물컵도 보지 않고 '물은 충분히 남아있어!'라고 생각하지 않기를 바라는 마음에서 주관적인 평가를 내리기 위한 보다 객관적인 자료를 제시하는 겁니다.
가상메모리(Virtual Memory)
운영체제는 프로그램이 마음껏 메모리를 사용할 수 있도록 가상메모리를 할당합니다.
위 사진을 보면, 실제 사용량은 308MB이지만 운영체제에서 해당 프로세스에 할당한 가상 메모리는 86GB입니다. 저 크기의 데이터를 실제 메모리에 확보해두려고 한다면 당연히 시스템 운영이 불가능할 겁니다. 프로세스가 사용할 수 있는 메모리 공간(86GB)과 실제로 메모리를 점유하는 크기(308MB)는 다르다는 것이죠. 이것을 '가상메모리'라고 합니다. 가상 메모리 덕분에 (보조 기억장치의 공간이 충분하다면) OS는 해당 프로세스가 실제로 86GB 를 요구해도 문제 없이 실행되도록 하는 것이죠. 단, 예상하다시피 속도는 처참할 겁니다.
가상 메모리란, 각 프로그램에 실제 메모리 주소가 아닌 가상의 메모리 주소를 주는 방식을 말합니다(위키피디아). 애플리케이션이 '메모리의 한계를 계산하고 그에 따라 메모리 사용량을 줄이도록 하는 복잡한 코딩/연산과정'을 생략할 수 있도록 하는 기법입니다. 실제로 프로그래밍을 할 때에 변수를 만들면서 메모리의 남은 공간을 확인하고 변수를 만들지는 않습니다. 오히려 프로그래머들은 연산을 시작하기 전에 일단 변수 먼저 만듭니다. CPU의 연산 속도에 비해 램이 느리기 때문에 먼저 공간을 만들어두는 것이죠. 이런 식의 프로그램은 메모리 점유율이 커질 수밖에 없습니다. 그러나 메모리의 한계에 다다른다 하더라도 프로세스가 종료되거나 멈추지 않습니다.
이러한 방식은 멀티태스킹 운영 체제에서 흔히 사용되고, 실제 주기억장치보다 큰 메모리 영역을 제공하는 방법으로도 사용됩니다(위키피디아). OS는 애플리케이션에 메모리가 충분히 많다고 전달하고, 애플리케이션은 그 충분한 공간을 사용할 수 있게 됩니다. OS는 애플리케이션의 요구에 맞춰 메모리에 데이터를 저장합니다.
메모리 압축과 Swap (Paging)
그런데 만약 실제 메모리가 부족하다면 어떻게 할까요? 어차피 프로세스들은 OS를 통해 메모리에 접근하는 것이기 때문에 프로세스가 요구하는 메모리 데이터가 어디에 저장되든 상관 없습니다. 그 점을 이용해서 OS는 메모리 압축이나 Swap을 통해 공간을 확보합니다. 자주 사용하지 않을 것 같은 데이터는 압축하거나, 보조 기억 장치에 저장하는 거죠.
메모리가 부족하다는 것은 메모리 압축이나 Swap(스왑)이 발생할 때를 말합니다.
메모리 압축
압축은 딱히 설명할 게 없습니다. 메모리에서 자주 사용하지 않는 코드를 압축하는 거죠. 압축을 하면 50%넘게도 크기를 줄일 수 있습니다. 압축의 단점은 CPU 리소스를 사용한다는 것입니다. 컴퓨터의 모든 리소스 중 가장 빠른 리소스이지만, 컴퓨터의 성능에 가장 큰 영향을 미치는 리소스이기도 하죠. 압축한 데이터에 다시 접근해야 한다면 압축을 풀어야 합니다. OS가 사용자의 요구를 미리 예측할 수 없기 때문에 메모리에 접근하고자 할 때에 메모리 압축 해제를 하게 됩니다. 이 때 성능에 큰 영향을 끼치는거죠.
Swap (Paging)
스왑은 보조 기억장치를 주 기억장치처럼 활용하는 기법을 말합니다. 보조 기억장치는 CPU에 비하면 압도적으로 느립니다(다음 절에서 설명). 그렇기 때문에 스왑을 하더라도 일단은 압축을 해야 합니다. 그만큼 CPU 리소스를 사용할 수밖에 없습니다. 그리고, 발열 전력소비에도 영향을 끼치죠. 노트북의 경우는 발열이 늘면 성능 감소로도 이어집니다. 여기서도 메모리 압축과 같은 문제가 발생합니다. 압축하고 스왑한 데이터를 다시 사용하려면 보조 기억장치에서 주 기억장치에 불러와서 압축을 풀어야 합니다. 보조 기억장치의 기나긴 응답을 기다리고, 메모리에 로드 되면 성능에 가장 큰 영향을 미치는 CPU 리소스를 사용해 압축을 풀어야 합니다.
메모리 압축과 Swap의 결론
컴퓨터는 하드웨어 간의 속도 차이를 극복하기 같은 계층 구조를 사용합니다. CPU가 가장 빠르고, CPU 안에 있는 L1, L2, L3 캐시, 그 다음으로 주 기억장치, 보조 기억장치 순서입니다. 최고의 성능 발휘를 위해서 프로그래머나 OS, CPU 연구원들은 캐시를 활용하여 RAM에 엑세스하는 것을 최대한 줄여야 합니다. 사용자는 RAM이 부족해서 압축이나 Swap을 위해 보조 기억장치에 엑세스하는 것을 최대한 줄여야 합니다.
SSD도 느린가요?
만약 보조 기억장치의 리소스 사용량이 적고, 주 기억장치와 CPU의 리소스 사용량이 많은 연산을 한다면 압축은 하지 않고 Swap만 하는게 유리할 수도 있습니다. 하지만 보통은 그러지 않습니다. 보조 기억장치로 사용되는 SSD가 아무리 빨라졌다 하더라도 주 기억장치인 램에 비하면 굉장히 느립니다.
2018년 기준 최상급인 삼성 SSD 970 Pro나 Intel SSD 900P의 응답 속도가 70마이크로초~150마이크로초 수준입니다. 램은 2018년 기준 낮은 수준인 2133Mhz 메모리의 응답 속도가 50나노초 정도로, 마이크로초로 계산하면 0.05마이크로초가 됩니다. 1400배 빠른 응답 속도를 갖습니다. 이런 차이가 장기적으로 누적되면 큰 지연이 생기죠.
SSD보다도 1000배 이상 빠른 RAM도 연산 장치인 CPU에 비하면 굉장히 느립니다. 이런 속도 차를 극복하기 위해 CPU는 L1 캐시를 사용합니다. 최근에는 그 속도차이가 더 커져서 L2, L3, L4캐시도 등장했습니다.
Computer Action
Avg latency
1초 정규화
3Ghz CPU Clock Cycle
0.3 ns
1s
L1 Cache Access
0.9 ns
3s
L2 Cache Access
2.8 ns
9s
L3 Cache Access
12.9 ns
43s
RAM Access
50ns
2.75 m
NVMe SSD I/O
70 ~ 150 us
2h ~ 2 d
Rotational disk I/O
1~10 ms
11d ~ 4 m
캐시
반대로 보조 기억장치가 느린 것을 보상하기 위해 메모리를 활용하는 기법이 있는데, 이를 캐시라고 합니다.
사진을 보면 Memory 열에서는 214MB, Real Memory 열에서는 309MB라고 나옵니다. 프로세스가 사용하는 메모리는 214MB인데, OS에서는 이 프로세스에 309MB를 사용합니다. OS가 자주 사용되는 코드, 그래서 추후 다시 사용 될 것 같은 코드를 미리 프로세스에 붙여두는거죠. 보조 기억장치가 너무 느리기 때문에 운영체제는 자주 사용되는 코드를 메모리에 보관하여 보조 기억장치에서 로드해야 할 코드를 메모리에서 찾는 겁니다.
OS의 가상메모리 운영
가상메모리에 신경써야 할 요소가 더 있습니다.
애플리케이션이 잘못 만들어진 것이 아니라면 갑자기 100GB이상의 메모리 데이터를 만들진 않을 겁니다. 하지만 1~2GB의 메모리 공간을 갑작스럽게 요구할 경우는 있겠죠. 그런데, 이 때 메모리가 부족하다면 어떻게 될까요?
운영체제는 애플리케이션이 메모리 공간을 추가로 요구할 때마다
CPU 자원을 사용해서 자주 사용하지 않는 코드를 찾아내고
CPU 자원을 사용하여 압축하고
보조 기억장치에 보관하는 동안 CPU 자원은 유휴 상태로 대기하고
보조 기억장치에 저장되면 메모리를 비우고 실행중인 애플리케이션에 할당
하는 작업을 반복 하는 걸까요?
만약 사실이라면 컴퓨터에서 애플리케이션을 실행하는 속도는 처참할 겁니다. OS는 애플리케이션이 어느 정도의 메모리 공간을 요구하는 것을 예측할 수 없기 때문에 애플리케이션이 1~2GGB의 공간이 필요하다 하더라도 실제로는 작은 크기의 데이터를 할당받는 것을 수백 번 반복하는 것입니다. 그 말은 자주 사용하지 않는 코드를 찾아 압축하는 작업을 수백번 반복하는 것이 됩니다.
개발자가 애플리케이션의 실행에 필요한 공간을 계산하여 미리 할당받는 방법도 있긴 하지만, 메모리 사용량을 예측할 수 없다면 필요할 때마다 추가로 요청해야 합니다. 그러라고 가상메모리라는 개념을 만든 것이기도 합니다. 게임으로 예를 들자면, 처음에 최대한 많은 데이터를 메모리에 로드해두는 방법도 있을겁니다. 하지만 대부분 게임은 라운드가 시작되거나 맵이 바뀔 때마다 다시 로딩을 합니다. 그런데 이렇게 애플리케이션이 실행되는 중에 로드하는 데이터들의 크기를 프로그래머가 예측하고 미리 할당받아두기는 쉽지 않습니다. 맵을 로드할때, 건물 개체와 그 개체에 그려질 그림(텍스처)를 로드해야 하는데, 미리 그 크기를 계산할 게 아니라면 건물 개체를 로드하고 다시 텍스처를 로드하는 방법을 사용해야 합니다. 게임 안에 건물이 몇개 나올까요? 엄청 많을겁니다. 그러므로 애플리케이션에서 수행하는 대용량의 메모리 공간 요청도 작은 크기의 메모리 할당을 여러번 반복하는 것이죠.
운영체제는 항상 어느 정도의 공간을 비워두도록 합니다. 덕분에 갑작스럽게 메모리를 요구할 때도 즉시 메모리를 할당하고 해당 애플리케이션이 다음 명령을 실행할 수 있습니다. 보통 OS는 10%~30%정도의 공간을 남겨둡니다. 주 기억장치가 8GB인 시스템에서는 2.5GB이하의 공간만 남아있다면 성능에 영향을 줄 정도로 압축이나 스왑이 된 것을 의심해야 합니다. 16GB의 시스템에서는 5GB이하의 공간만 남아있다면 성능에 영향을 줄 정도로 압축이나 스왑이 된 것을 의심해야 하는 겁니다.
본격적인 판단 기준
처음에도 언급했듯이, 주관적인 판단을 위한 객관적 지표인겁니다. 바로 윗 단에서 2.5GB 이하의 공간만 남아있다면 성능에 영향을 줄 정도라고 했습니다. 하지만 이 '성능'은 '체감 성능'이 아닙니다. '성능'만을 따진다면 메모리는 100GB로도 부족할겁니다. 캐시 기능이 덕분에 메모리는 많을수록 빨라집니다. 물론, 그 돈을 투자해서 CPU를 업그레이드 하는게 체감 성능은 더 좋아지겠죠. 이런 주관적인 판단을 위해 사용할 객관적 지표 '가상메모리'를 배웠습니다.
그러면 캐시는 없더라도, 압축이나 스왑이 없는 정도로 업그레이드 하면 될까요? 그것도 아닙니다. 압축이나 캐시가 있어도 됩니다. 아무리 시간에 민감한 사람이라도 '체감 성능' 기준으로 차이가 느껴지지 않을 수 있습니다.
1. 불필요한 데이터의 압축
메모리 압축은 자주 사용하지 않는 데이터를 대상으로 수행됩니다. 압축된 메모리를 사용할 때는 다시 압축을 해제해야 하기 때문에, 자주 사용하는 데이터에 적용하지는 않을겁니다. 그 중에서도 정말로 사용하지 않는 코드인 경우에는 압축되거나 Swap되어도 성능에 영향이 없습니다. 프로세스가 통채로 압축되는게 아니고 프로세스의 일부만 압축할 수도 있습니다. 그래서 모든 프로세스를 골고루 사용중이라도 그 중 일부 기능은 자주 사용하지 않는다면 압축되어도 체감 차이는 없을 수 있습니다.
2. 부속 장치를 기다림
다른 장치를 기다려야 하는 애플리케이션이라면 체감되지 않을 수 있습니다다.
HDD 불량 확인 프로그램으로 HDD를 검사한다고 가정합시다. 이 컴퓨터의 메모리가 부족하여 Swap 되더라도 컴퓨터는 하드디스크의 불량 확인 속도에 체감하는 차이가 없을 것입니다. 여기서 생기는 가장 큰 지연은 HDD의 지연이기 때문입니다. CPU나 램은 Swap 때문에 연산량이 늘어났지만, 어차피 HDD를 기다려야 하는 시간 때문에 유휴 시간이 더 깁니다.
간단히 커서를 움직이는 동작을 비교해봅시다. 한 컴퓨터는 1Ghz 듀얼코어 컴퓨터이고, 한 컴퓨터는 4Ghz 옥타코어입니다. 그 외 스펙은 모두 같습니다. 아무것도 없는 바탕화면에 커서만 움직이는데 체감 차이가 느껴질까요? 아닙니다. 분명 같은 연산을 수십배 이상 느린 컴퓨터에서 수행하는건데 왜 체감 차이가 없을까요? 그 이유는 이 상황에서는 모니터의 지연이 원인이기 때문입니다. 보통의 60Hz모니터는 약 16ms의 지연을 가집니다. 1Ghz 듀얼코어 시스템이라 하더라도 마우스를 움직이는데 16ms까지 필요하지는 않은게 그 이유입니다..
메모리 확인 방법
위에서 알아본 이론적인 구조를 직접 확인할 수 있어야 메모리 업글레이드가 필요한지 알 수 있습니다. 보조 기억장치는 느립니다. 그렇기 때문에 보조기억장치를 사용하는 Swap은 최후의 단계라고 보면 됩니다. 개인적으로는 Swap 크기가 2GB이상일 경우는 누구라도 속도 차이를 느낄 수 있다고 생각합니다. 메모리 압축은 5GB 이상이라면 누구라도 속도 차이를 느낄 수 있을 것이라고 생각합니다.(16GB램 기준) 여기서 함께 확인해야 할 것은 자신의 사용 환경과 가격 부분을 고려해야 합니다. 만약에 백그라운드형 프로그램이 굉장히 많고, 이 프로그램들이 반복적인 코드만을 수행한다면 스왑이나 압축이 굉장히 커도 큰 차이는 없을 겁니다. 필요 없는 부분만 압축했기 때문이죠. 또한 체감 차이가 생긴다 하더라도 메모리 가격 대비 유익한 체감차이인지도 생각해봐야 하고요.
맥OS(MacOS)
맥은 메모리가 항상 캐시로 가득 차 있습니다. 어느 정도 사용하고 나면 여유 메모리는 300MB미만이 됩니다. 또한 맥은 Swap을 하는 한이 있어도 일단은 캐시는 어느 정도 남겨둡니다. iOS도 같습니다.
활성 상태 보기(Activity Monitor) 앱을 실행합니다. 그리고 메모리 탭을 클릭하면 위와 같이 나옵니다. 아래쪽에 Swap Used와 Compressed를 통해 전체적인 압축량과 스왑 사용량을 확인할 수 있습니다. 맥은 활성 상태 보기에서 앱별 압축된 양도 확인할 수 있습니다. 메뉴바에서 '보기 -> 열 -> 실제 메모리, 압축 된 메모리'를 체크하면 됩니다. 여기서 각 프로세스별로 압축된 양을 보고 시스템 업그레이드가 필요할지 주관적으로 판단하면 됩니다.
맥의 경우는 Hibernate를 할 때에 메모리의 데이터를 최대한 압축하고 스왑한 후에 컴퓨터를 끕니다. 덕분에 16GB 메모리를 사용 중이라도 Hibernate 파일은 3GB를 넘지 않죠. 그런데 시스템이 복원 된 후에도 다시 사용하지 않는 코드는 메모리가 여유롭다 하더라도 스왑 상태로 남습니다. 이를 속도가 저하되는 요인이고, 메모리 업그레이드 후에 체감 차이가 생긴다고 여기면 안됩니다.
주 : Hibernate : 메모리의 데이터를 보조기억장치에 저장하고 컴퓨터를 끕니다. 컴퓨터를 켜면 이 데이터를 복원하고 잠자기(Sleep)에서 깨어난 것처럼 작동합니다.
윈도우(Windows)
윈도우즈가 올바른 외래어 표기입니다. 하지만 한국 MS가 윈도우라고 표기합니다. 고유명사가 표기법보다 우선이니 '윈도우'라고 해야 합니다.
윈도우는 작업 관리자에서 성능 탭을 보면 됩니다.
Swap을 윈도우에서는 페이징(Paging)이라고 합니다. 윈도우의 경우 페이징은 정확한 수치로 나오지 않습니다. 여기서 확인해야 할 것은 Committed(커밋 됨)과 In use(사용 중), 그리고 Compressed(압축 됨)입니다. Commit은 OS에서 메모리를 할당한 부분입니다. 캐시를 포함하여 압축, 페이징 크기도 Committed에 포함됩니다..
'In use(사용 중)' + 'Available(사용 가능)' = 사용 가능한 RAM 크기 : 캐시나, 페이징에 대한 부분은 계산에서 제외됩니다. 그래서 실제 메모리 사용량과는 다릅니다.
'Committed(커밋 됨)' = 주소를 가진 데이터의 크기 : 압축 된 데이터나 페이징 된 데이터는 압축 이전의 크기로 표시될 수 있습니다. 'In use(사용 중)', 'Paged pool(페이징 풀)*', 'Non-paged pool(비 페이징 풀)**', 'Paging***' 등을 포함합니다. 'Cached(캐시 됨)'은 'Committed(커밋 됨)'에 포함되지 않습니다. *페이징 풀은 RAM에 있는 커널 개체에 대한 가상 주소를 보관합니다. **비 페이징 풀은 RAM 외의 장치에서 가져올 수 있는 데이터에 대한 가상 주소를 보관합니다. ***페이징 파일이 있을 경우에는 Committed(커밋 됨) 항목의 분모가 전체 메모리 크기보다 큽니다(커질 가능성이 높다).
CPU가 보조 저장장치에 비해 압도적으로 빠르기 때문에 페이징을 할 때도 압축을 거친 후에 보조 저장장치에 저장합니다. 그런데 윈도우에서는 실제 페이징 크기나 압축 크기가 아닌, 압축 이전의 크기만 나옵니다. 그래서 압축 전의 데이터 크기와 페이징 이전의 크기를 가지고 주관적으로 판단해야 합니다.
하지만 윈도는 또 다른 객관적 자료를 제공합니다.
Resource Monitor(리소스 모니터)의 메모리 탭에서 Hard Faults(하드 폴트)를 확인할 수 있습니다. 이 열은 프로세스가 초당 하드 페이지 폴트 요청 횟수의 1분 동안의 평균치를 보여줍니다. 자주 사용하는 프로그램이 하드 폴트가 많으면 메모리를 늘릴 필요가 있는겁니다. MacOS에서는 페이지 폴트를 서드파티(3rd Parties) 프로그램을 이용하면 확인할 수 있습니다.
마치며…
처음부터 강조한 것인데, 개인의 선택에 달린겁니다. 하지만 단순히 OS가 표시하는 RAM의 사용량만 보는 것은 선택에 대한 근거로는 부족하죠. 그래서 OS가 메모리를 관리하는 방법을 알아보고 메모리가 얼마나 사용되고 있는지 더 정확하게 추정한 후에 주관적으로 결정해야 합니다. 사용자의 컴퓨터가 사용자가 하고자 하는 작업에 사용자가 요구하는 성능을 보여줄 수 있는지 생각해봐야 합니다.
OS는 상당히 복잡하여 현재의 구성에서 각종 프로세스와 하드웨어를 조절하여 각종 요소의 균형을 유지할 수 있도록 동적으로 관리합니다. 때문에 단순히 컴퓨터의 리소스 사용량만을 보고 판단하기 어렵죠. 이는 RAM 뿐 아니라 다른 장치들도 마찬가지입니다. CPU는 캐시의 속도에 따라서도 성능 차이가 생기고, 디코더의 속도에 따라서도 성능 차이가 생깁니다. 그래서 CPU사용량이 30%정도라 해도 업그레이드를 하면 성능 차이가 느껴질 수 있죠. 캐시 또한 성능에 영향을 미치는 요소이지만 작업 관리자에 나타나지 않습니다. SSD도 마찬가지입니다. 단순히 읽기 속도가 빠른 것만이 장점인 것은 아닙니다. SSD는 읽기/쓰기 요청에 대해 응답속도가 굉장히 빠른 것이 장점입니다. 이 장점을 살리는 인터페이스가 NVMe구요. 초당 IO 처리 횟수를 의미하는 IOPS는 단순한 파일 복사로는 판단할 수 없습니다. 작은 크기의 파일을 여러 개 복사해야 IO요청이 여러개 생기기 때문이죠. 이건 벤치마킹 소프트웨어를 통해 판단할 수 있습니다. GPU와 HDD에 대해서도 단순히 사용량만 확인할 것이 아니라 좀 더 다양한 기준을 찾아 평가할 필요가 있습니다.
레인보우식스 시즈의 벤치마킹 기능을 이용했다. 그래픽 옵션은 프리셋 최상에, 텍스처는 Very High, 안티앨리어싱과 텍스처 필터링은 끈 상태로 진행했다. 인코딩은 6000kbps로 설정했다.
GPU는 소수연산에 효율적이기 때문에 그걸 강조하기 위해 전력소비도 비교해봤다. 전력소비는 소프트웨어 기반이기 때문에 정확하지 않을 수 있다.
게임 플레이
Time
CPU [%]
GPU [%]
FPS [FPS]
CPU Package Power [W]
GPU Chip Power [W]
Power Combined
max
61.3
100
157
62.268
149.082
206.956
min
20
87
90
46.378
123.465
174.619
avg
44.3
99.8421052631579
120.031578947368
54.7037263157894
135.544189473684
190.247915789474
CPU사용량은 최대 61%, 평균 44%이다.
FPS는 최대 157FPS, 최소 90FPS이고, 평균은 120FPS이다. 편차는 60FPS.
CPU와 GPU의 최대 전력소비량은 207W이다.
게임 플레이 + CPU 인코딩
Time
CPU [%]
GPU [%]
FPS [FPS]
CPU Package Power [W]
GPU Chip Power [W]
Power Combined
max
79.5
100
144
82.233
145.098
225.527
min
32.6
88
88
64.547
127.582
198.656
avg
60.3
98.7894736842105
112.252631578947
73.780
134.084557894737
207.864284210526
CPU사용량은 최대 80%, 평균 60%이다. 인코딩을 하지 않을 때에 비해 평균값은 16%차이, 최대는 19%가까이 차이난다.
FPS는 최대 144FPS, 최소 88FPS, 평균 112FPS이다. 녹화하지 않을 때보다 8FPS정도 떨어진다. 편차는 56FPS.
최대 전력소비는 225W이다. 18W차이이고, 10%가 늘어난 것이다.
게임 플레이 + GPU 인코딩
Time
CPU [%]
GPU [%]
FPS [FPS]
CPU Package Power [W]
GPU Chip Power [W]
Power Combined
max
88
100
141
66.048
143.406
200.306
min
18.7
87
88
50.234
128.52
182.815
avg
49.3631578947369
99.2210526315789
111.536842105263
56.3260315789474
135.858810526316
192.184842105263
CPU사용량은 최대 88%, 평균 49%이다.
FPS는 최대 141FPS, 최소 88FPS, 평균 111FPS이다. 프레임은 CPU인코딩에 비해 낮다. 편차는 53FPS.
최대 전력소비는 200W이다. 녹화하지 않을 때에 비해 오히려 줄어들었다.
뒤쪽에 그래프를 게시할 것인데, 녹화 때문에 프레임이 줄어드니 오히려 전력소비가 감소한 것으로 추측해 볼 수 있다.
게임 플레이 + NDI 전송
Time
CPU [%]
GPU [%]
FPS [FPS]
CPU Package Power [W]
GPU Chip Power [W]
Power Combined
max
51.6
100
147
80.255
145.574
215.345
min
13.7
90
94
32.769
131.828
169.890
avg
39.2178947368421
99
119.326315789474
54.938
139.662978947368
194.600694736842
CPU사용량은 최대 51%, 평균 39%이다. 평균값이 GPU인코딩과 별 차이 없다.
FPS는 최대 147FPS, 최소 94FPS, 평균 119FPS이다. 편차는 53FPS.
최대 전력소비는 215W이다. 다른 컴퓨터에서 인코딩을 해야 하니 결코 적은 수치는 아니다.
차트 비교하기
단순 게임 플레이
GPU사용량에 변화가 없이 안정적이다.
CPU사용량은 FPS에 따라 조금씩 변하고 있다. 13번째~41번째 스캔에서는 FPS에 따라 낮아지고, 거의 40%이하로 유지되고 있다.
CPU 인코딩
GPU사용량이 출렁이는 지점이 많다.
CPU사용량은 거의 60%대에서 변화한다. 갑자기 CPU 사용량이 떨어지는 지점은 인코딩 과부화로 영상 출력이 끊기는 부분이었다.
전체적인 FPS그래프가 인코딩을 하지 않을 때와 비슷하다.
GPU 인코딩
GPU 사용량이 출렁이는 지점이 많다. CPU 인코딩에 비해서는 적다.
65번째~75번째 스캔에서 CPU 사용량이 크게 증가한다. 위 표에서 GPU 인코딩 중의 CPU 사용량 최댓값이 88이어서 GPU 인코딩의 장점을 부각하지 못했다. 녹화 영상이나 게임 벤치마킹에서는 별 문제가 발견되지 않았다. 인코더가 불안정하거나 다른 프로세스가 갑자기 실행된 것일 수도 있다.
꼭짓점이 부드럽다고 해야할까, 전체적인 FPS 그래프가 좀 다르다.
NDI 인코딩
CPU 사용량이 다른 인코딩에 비해 안정적이다.
GPU 사용량은 자주 출렁인다. 하지만 다른 인코딩 방식처럼 크게 떨어지지 않는다.
결론
각각의 장단점이 있다. NDI는 리소스를 분산시킬 수 있지만 전체적으로는 가장 비효율적인 방법이다. 또한 좋은 네트워크 장비가 요구된다.
GPU는 전체적으로 CPU, GPU사용량에 큰 변화 없이 인코딩이 가능하다. 프레임 감소는 제일 크다.
CPU는 전력소비는 크지만, 대체로 안정적이다. FFmpeg라는 인코더가 안정적인 것도 있지만, CPU는 리소스 분배에 있어 비교적 여유롭기 때문이다.
GPU로 코덱은 GPU 업체에서 코덱 라이브러리를 개발하여 배포하는 것이기 때문에 업체별로 다르다.
AMD의 GPU를 사용하기 때문에 AMD를 기준으로 설명할 것이다.
Encoder를 H264/AVC Encoder (AMD Advanced Media Framework)를 선택하면 AMD GPU로 인코딩을 할 수 있다.
Quality를 Speed로 설정할 경우 품질이 너무 낮아지기 때문에 Balance 이상으로 설정하는것이 좋다.
FFmpeg의 경우는 x264 Options 항목에서 사용자가 원하는 Parameter를 설정할 수 있었는데, View Mode를 Basic이 아닌 다른 설정을 선택하면 AMD도 다양한 Parameter를 지정할 수 있다.
FFmpeg 코덱은 현재 프레임과 바로 이전 프레임의 움직임 비교만 하는 것이 기본값이다. 하지만 AMD는 4개 이전의 프레임까지 비교하는것이 기본값이기 때문에 원하지 않는다면 고급 설정을 통해 줄일 수 있다. 위 사진에서 두번째 빨간 박스인 Maximum Reference Frames를 줄이면 된다.
WBAQ는 인지 특성을 고려하여 인코딩하는 것이다. 특정 상황에서 성능 향상이 있다.
Enforce HRD는 Encoding을 한 출력물이 올바른지 검사하는 HRD를 강제로 사용하도록 한다. 이 옵션을 끌 때는 오랫동안 영상을 Encoding하면서 문제가 없는지 확인할 필요가 있다.
OpenCL Transfer는 Frame을 Mapped Memory 대신 OpenCL을 통해 전송는 기능이다. GPU 메모리의 사용량이 많은 경우 OpenCL을 사용하는게 도움이 될 수 있다.
GPU로 녹화를 하고자 한다면 내장그래픽도사용이가능하다는 것을 고려해보면 좋다.보통은외장그래픽이추가되면내장그래픽이꺼진다. 그래서 바이오스에서 수동으로 사용가능하도록 설정해야 한다. 내장 그래픽은메인메모리를사용하기때문에 CPU, GPU 처리에 영향은없지만메모리가느려져성능하락이발생할수있다.
GPU는인코딩연산에특화되어있기때문에더적은전력소비, 더적은발열량으로인코딩이가능하다. 그러므로 녹화하려는장면이 CPU를주로사용하는지, GPU를사용하는지알기어렵고, 같은인코딩설정으로어떤프로그램이든녹화하고싶다면 GPU인코딩도 좋은 선택이다.
컨텐츠를 만들고, 컨텐츠 소비자와 소통하고자 하는 1인 미디어의 시대가 열렸다. 취미 활동으로 자신의 예술적 감각을 뽐내기도 하고, 때로는 직업으로써 1인 미디어를 운영하기도 한다. 이때 반드시 인코딩과정을 거쳐야 하는데, 인코딩의 리소스 사용량이 결코 적지 않아 컴퓨터 시스템에 부담이 된다. 그 중에서도 게임 방송이나 컴퓨터 관련 강좌를 녹화할 때에는 리소스 사용량이 너무 커서 양질의 컨텐츠를 제작하는데에 어려움이 있다. 녹화하려는 게임의 플레이에 방해가 되거나 작업이 늦어지고, 방송이 끊기는 등의 상황은 컨텐츠 소비자에게 집중력을 떨어트리기 십상이다.
녹화가 리소스를 많이 사용하는 이유는 동영상을 어떻게 저장해야 할지 고르는데 있어서 연산이 굉장히 많이 필요하기 때문이다. 이를 인코딩이라고 하는데, 인코딩 툴이나 인코딩 툴의 옵션에 따라 품질이나 리소스 사용량에 차이가 크다. 동영상은 매 프레임을 사진처럼 저장하지 않는다. 키 프레임이라는 사진과 같은 프레임이 있고, 그 사이는 각 픽셀들의 움직임을 분석하여 저장한다. 같은 인코더를 사용한다면 이 움직임의 분석 방법에 따라 리소스 사용량이 변한다. 물론, 그 움직임의 분석 방법에 따라 결과물의 품질 차이도 크다.
그러므로 인코딩툴을 변경하거나 옵션을 적절히 조절하여 컨텐츠의 품질과 영상의 집중력 사이에서 적절한 조절이 필요하다.
앞서 인코딩의 변수로 제시했던 인코딩 툴은 사실상 하나밖에 없다. 무료이면서도 리소스 점유율 대비 품질이 좋은 코덱은 FFmpeg뿐이다. 그러므로 다른 변수들을 고려할 필요가 있다. 품질을 조절하면 리소스 사용량을 조절할 수 있다. 아니면 아예 새로운 접근으로 인코딩을 다른 프로세서로 처리하는 방법이 있다.
이번 주제에서는 그 방법을 소개해보려고 한다.
CPU 인코딩
가장 기본적이고, 전통적인 형태의 인코딩 방법이다. 6코어, 8코어 CPU가 보편화 되면서 가장 큰 혜택을 받는 부분이 동영상 인코딩이다. 인코딩은 병렬 연산이기 때문에 코어 수에 크게 영향을 받는다. 일반적으로 코어 수가 두 배가 되면 평균 약 1.6배의 성능 향상이 생기는 것으로 계산하는데, 인코딩은 코어 수가 두 배가 되면 1.8배 이상으로 2배에 근접한 성능이 나온다. 멀티코어 퍼포먼스의 평균치를 총대메고 끌어올리는 연산이 동영상 처리인 것이다. 그러니 요즘의 컴퓨터라면 CPU만으로도 인코딩 하는데에 큰 부담이 되지는 않는다. CPU 인코딩은 대체로 편차가 적다는 장점이 있다. 그래픽처리(*게임)를 할때 CPU는 대체로 연산량이 비슷하지만, GPU는 연산량이 큰 폭으로 변한다. 화면에 보이지 않는 것들은 모두 자르고, 멀리 있는 개체들은 밉맵 기법으로 처리량을 줄인다. 모든 개체가 화면 안에 있고, 점점 가까워진다면 CPU 대비 GPU요구량이 크게 증가한다. 하지만 인코딩 과정 자체에서 장면이 복잡해질수록 CPU 리소스 요구량이 많아지기 때문에 인코딩까지 고려하면 꼭 그렇지만은 않다.
GPU 인코딩
앞서 말한 것과 같이 동영상 인코딩은 병렬 소수연산의 연속이기 때문에 GPU인코딩이 더 효율적이다. 메인스트림급 GPU는 소숫점 연산 유닛이 천 개에 달한다. 하이엔드급 GPU는 소숫점 연산 유닛이 4000개를 넘는다.때문에 병렬 연산에 좋고, 인코딩에 효율적이다. 소수 연산 전용인만큼 같은 처리를 하더라도 점유율과 전력소비가 더 낮다.
단점은 GPU를 사용하는 프로그램에 있어서는 편차가 더 커질 수 있다는 것이다. CPU와 GPU를 포함한 프로세서들은 연산을 하기 전에 명령어를 디코딩하는데, GPU는 이 과정에 필요한 장치가 적기 때문이다. 일반적으로 CPU는 2개의 디코더에 1개의 정수연산유닛과 소수연산 유닛이 연결되고, GPU는 1개의 디코더에 64개의 소수연산유닛이 연결되기 때문이다. 즉, 동영상 인코딩만 한다면 GPU처리가 유리하지만 동영상 인코딩과 게임 등의 그래픽 처리를 한다면 디코더가 많은 CPU인코딩이 유리하다.
2-PC 인코딩
위 두가지 방법은 녹화 대상이 되는 프로그램이 CPU를 많이 사용하는지 GPU를 많이 사용하는지에 따라 인코딩 설정을 변경하는게 좋다. 아예 다른 컴퓨터로 인코딩을 하면 어떤 작업을 하든 인코딩이 영향을 끼치지 않는다. 디스플레이 출력은 초당 40Gbps에 달하는 데이터를 전송한다. 이 영상을 다른 컴퓨터로 전송하고자 한다면 40Gbps를 지원하는 인터페이스(포트)가 필요하다. 하지만 그런 인터페이스는 디스플레이 포트 뿐이다. 디스플레이 출력을 다시 다른 컴퓨터에 입력시켜주는 캡처 보드는 10만원을 넘어간다. 1080p영상을 지원하는 캡처카드는 30만원이 넘어간다.
그럼에도 2-PC 인코딩을 소개하는 이유가 있다. 바로 NDI에서 제공하는 프로그램을 사용하는 것이다. 원래는 그래픽 작업에 있어서 협업을 위한 툴로 개발되었지만 obs에서 지원하면서 NDI 자사 홈페이지에도 obs를 이용하는 방법을 제시하고 있다. NDI의 최대 장점은 캡처 보드가 없어도 리소스 사용 거의 없이 2-PC 인코딩이 가능하다는 것이다. OBS는 실행하는것만으로도 GPU리소스를 어느정도 사용하는데, NDI자체 툴을 이용하면 1%이내의 리소스 사용으로 2-PC인코딩이 가능해진다. 이전에도 말했지만, 인코딩은 데이터를 줄이기 위한 방법을 고르는 것 때문에 연산이 늘어나는 것이다. 반대로 NDI는 영상의 데이터를 줄이긴 하지만 연산이 그렇게 많지는 않고, 데이터 크기가 많이 줄지 않는다. NDI는 영상을 네트워크를 통해 전송한다. 영상의 데이터가 크기 때문에 두 컴퓨터가 1Gbps의 속도를 지원해야 한다. 게임 영상을 일반적으로 6000kbps 수준으로 녹화하는데 반해 NDI는 500Mbps(500000kbps)수준으로 녹화한다.
예고
이 강좌에서는 녹화 및 방송에 있어서 오픈소스 소프트웨어인 OBS만을 이용할 것이다.
OBS는 FFmpeg 코덱을 사용한다. 또한 CPU 인코딩과 GPU인코딩을 번갈아가며 사용하거나 영상에 오버레이를 넣고,마이크를 사용하는 데 있어서는 OBS가 이용하기 편하기 때문이다.
OBS는 Open Broadcaster Software로 오픈 소스 개인 방송용 소프트웨어이다.
방송에 필요한 기본적인 도구들을 제공하고 플러그인을 통해 다양한 추가 기능을 제공한다.
설정에서는 출력 부분을 제외하고는 설명할 부분이 없다.
출력은 인코딩 방법에 따라 추후 설명한다.
장면과 소스
OBS에서 화면을 출력하려면 장면을 만들고, 소스를 구성하면 된다.
소스에는 장면에 표시할 요소를 추가할 수 있는데, 창 사진 동영상 브라우저 게임과 화면 전체 등을 추가할 수 있다.
게임을 출력하고자 할 때는 게임 캡처가 가장 리소스를 적게 사용하고 그 다음이 디스플레이, 마지막으로 창 캡처가 리소스를 제일 많이 사용한다. 창 캡처는 호환성 문제도 있어서 별로 추천하지 않는다.
또한 소스에는 장면도 추가할 수 있는데, 위 스크린샷에서 Overlay와 ㅋㅎ배경은 장면을 추가한 것이다. "ㅋㅎ배경" 장면은 화면 가운데에 프로필 이미지가 보이는 바탕화면인데, NDI Source가 아무것도 확인이 되지 않으면 자동으로 바탕화면이 보이도록 해준다. Overlay는 왼쪽 아래 '콜홍'사진과 채팅 소스를 가지고 있다.
이렇게 구성해두면 추후 어떤 새로운 장면을 추가하더라도 프로필 사진과 채팅소스를 따로 추가할 필요가 없다.
믹서와 모니터
믹서는 녹음될 오디오 채널들을 표시해준다. 각 채널의 소리 크기를 보여주고, 믹싱을 하거나 모니터링 할 수 있다. 각 오디오 채널별로 오른쪽 톱니바퀴를 통해 오디오를모니터하거나 필터를 할 수도 있다.
채널별 입력되는 소리의 크기는 최대(피크)가 노란 부분을 넘지 않도록 하는게 좋다. 그 범위는 -20dB ~ -10dB이다. 대부분 음원 유통 채널은 -13~ -16LUFS로 정의하고,유럽 방송 기준은 -24 LUFS 이니 그 사이로 적당히 맞추면 된다.
dB는 기술적 단위이고, LUFS는 청각적, 감각적 단위이다. 사람은 저음과 초고음에 비해 사람 목소리에 해당하는 음에 대해 더 민감하게 반응하는데, 그걸 반영한 단위가 LUFS이다.
LUFS로 표시해주는 툴을 사용한다면 더 좋겠지만 dB만 잘 맞춰도 소비자가 듣기에 거북하지 않다.
믹서에서 오른쪽의 톱니바퀴를 눌러 Advanced Audio Properties를 클릭하면 각오디오 채널을모니터하고 조절하는 기능을 제공한다.
필터
일반적인 1인 미디어 제작 환경은 전문적인 환경과 다르기 때문에 입력되는 모든 오디오와 비디오를 녹화하기에는 개인정보가 포함되거나 컨텐츠 소비자가 듣기에 불편한 소리가 포함될 수 있다. 이를 없애거나 줄이기 위해 OBS에서 기본적으로 몇 가지 필터를 제공한다.
오디오를 위해서는 노이즈 게이트, 컴프레서 등이 있다. 노이즈 게이트는 사용자가 지정한 음성의 크기를 기준으로 그보다 더 작은 소리는 아예 출력하지 않는다. 컴프레서는 기준값 이상의 소리를 줄이는데, 갑자기 큰 소리를 내거나 물건이 떨어지는 소리처럼 예상하지 못한 큰 소리가 날 때 출력을 줄여 컨텐츠 소비자가 불편하지 않게 해준다.
비디오를 위해서는 크롭, 컬러 코렉션, 크로마 키 등이 있다. 크롭은 입력 영상을 잘라내고, 컬러 코렉션은 색감을 조절하는 필터이다. 크로마 키는 흔히 방송에서도 많이 사용하는 기능이다. 특정 색을 지정하면 그 색이 나타나는 부분은 영상 입력이 아닌 것, 또는 투명한 색으로 인식한다. 그러면 뒤쪽 레이어가 보인다. OBS에서는 뒤쪽 소스가 보이는 것이다.
필터를 간단히 설명한 이유는 필터는 직접 만져보며 배워야 한다고 생각하기 때문이다. 이론적인 내용보다 개인적인 선호와 주변의 상황에 맞는 필터들을 수많은 테스트를 거쳐 직접 결정하길 바란다.
플러그인
OBS에서 기본적으로 제공해주는 기능만으로도 충분하지만, 외부 플러그인을 추가하여 OBS를 200% 활용할 수 있다. 오픈 소스 답게 플러그인들도 다양하고 빠르게 변한다. 그렇기 때문에 플러그인도 여러가지 커뮤니티를 돌아가면서 찾아보면 좋다.
추천하는 플러그인으로는 NDI 플러그인과 리모트 플러그인이다. NDI는 추후 설명할 예정인데, 캡처카드 없이 2-PC 방송을 하기위한 플러그인이다. 리모트는 OBS를 원격으로 조절하는 플러그인이다. 원컴방송인 경우에도 모바일 기기의 웹 브라우저로 OBS 장면을 바꾸거나 방송을 송출/중단할 수 있다. 리모트 플러그인은 종류가 다양하니 직접 비교하며 찾아보면 좋다.
Intel은 4세대 Core 아키텍처인 Haswell 부터 Turbo Boost Technology를 도입했다. 이 때부터 TDP의 수치는 성능의 구분할 수 있는 지표가 되었다. 그래도 여전히 더 높은 스펙을 가진 제품이 더 높은 성능을 보여주었기 때문에 소비자들은 TDP에 큰 관심을 갖지 않았다.
하지만 Intel에서 8세대 Mobile Processor가 Quad Core로 출시되면서 TDP는 중요해졌다. 데스크탑, 고성능 노트북, 저전력 노트북 모두 쿼드코어인데, 여기서 성능의 차이는 TDP를 따라가기 때문이다.
TDP가 뭔가요?
TDP는 Thermal Design Power의 약자로, 열 설계 전력이라고 번역한다. 이렇게 번역하고 보니 많은 사람들이 전력이라고 착각한다. 또한 TDP의 단위에 W(watt)를 사용하니 더 착각하기 쉽다. 이런 착각이 생기는 원인은 파워의 번역이다. Power의 기본적인 뜻은 '힘'이다. 다만, 전자제품이고 사전에 전력이라는 뜻도 있으니 전력이라고 번역하기 쉽다.
실제로는 TDP는 전력과는 전혀 관계가 없다.
첫번째 이유는 열과 전력은 같은 위치에 있을 수 없다. 에너지 효율에 관한 위키피디아 문서를 보자. 에너지 효율이란 "투입한 에너지에 대해 이용할 수 있는 에너지의 비"이다.
에너지를 투입하면 에너지의 일부를 System에서 사용하고 에너지의 일부는 Loss된다. (실제로 그림처럼 효율이 높은 제품은 거의 없다.)
CPU에서 열은 일이 아닌 Loss이다. 즉, 발열량이 15W이면 전력소비는 반드시 15W를 넘어야 한다. 발열이 15W인데 전력소비가 15W라면 에너지 효율은 0이다.
그러므로 열과 전력은 비례 관계를 가질 수는 있지만 발열량이 15W라고 고정이 되면 열과 전력은 같은 공간에 있을 수 없다는 것이다.
두번째 이유는 TDP의 'Design(설계)'에 있다. 설계 전력이라고 하면 마치 15W의 전력소비를 넘지 않을 것 같다. 해당 CPU와 연결된 컴퓨터는 이 설계에 따라 15W를 제공할 수 있으면 충분한 구성을 가진 컴퓨터가 된다. 그러면 CPU는 Boost Clock을 이용할 수 없다. Boost Clock은 설계보다 더 많은 전력이 필요하기 때문이다. 아니면 CPU 내부에 Boost Clock을 이용할 때를 위해 전력을 저장하는 축전기가 있으면 된다. 반대로 열 설계라고 생각해보자. 해당 CPU와 연결된 컴퓨터는 CPU에서, 본체 내에서 15W의 열을 빼는 능력만 있으면 된다. CPU는 Boost Clock을 이용하면서 너무 많은 열이 CPU나 본체 내에 축적되면 쓰로틀링(Thermal Throttle)을 통해 열을 조절할 수 있다.
세번째는 논리가 아닌 경험적 근거이다. 필자의 CPU는 아래 라이젠의 소비전력 그래프와 거의 비슷한 수율을 가지고 있는데, Cooling 능력이 65W인 쿨러로 3.6Ghz까지 문제없이 오버클럭이 된다. 하지만 그래프를 통해 알 수 있듯이 소비전력은 130W 가까이 된다. TDP가 소비전력과 관계가 있다고 보기에는 그 차이가 크다.
그러니까 'TDP 가 15W이다' 라고 정의되었을 때, 여기서 15W는 전력이 아닌 발열량인 것이다.
그러므로 TDP는 열설계전력이라고 번역하는 대신 열설계력이라고 해석해야 한다. 물론 관용적으로 열설계전력을 사용할 수 있지만, 이 단어를 보면서 전력과는 관련이 없다는 것을 상기해야 한다.
TDP가 왜 중요한가요?
그렇다면 TDP를 왜 중요하게 봐야 할까? 단순히 해석만 하자면 CPU가 15W의 열을 배출할 수 있는 컴퓨터 환경을 전제로 하는 설계했다는 것이다. 이렇게 생각하면 다른 의문도 해결된다. CPU들이 클럭이 다른데도 TDP가 같은 경우가 있는데, 그 이유는 CPU의 스펙을 나타낸 것이 아니라 이 CPU를 사용하는 데에 필요한 외부의 쿨링 능력이었기 때문이다.
아래 비교군을 보자
인텔 i5-7600은 Turbo Clock 4.1Ghz를 가지고 있다. 인텔 i7-7920HQ도 Turbo Clock 4.1Ghz를 가지고 있다. 하지만 각각 베이스클럭 3.5Ghz, 3.1Ghz로 65W, 45W이다.
인텔 i7-7920HQ는 Clock Limit 없이 TDP 35W로도 구성이 가능한데, 데스크탑 프로세서도 TDP 36W인 제품이 있다. 인텔 i7-7700T는 Turbo Clock이 3.8Ghz로 차이가 크다. 반면에 Base Clock은 2.9Ghz로 Base Clock이 3.1Ghz인 i7-7920HQ와 비슷하고 TDP도 같다.
데스크탑 프로세서와 모바일 프로세서는 타겟이 다르다. 클럭이 같다고 하여도 구성이 다르다.
그럼에도 불구하고 위 제품들에서 TDP와 Base Clock은 큰 연관이 있다는 것을 알 수 있다.
베이스 클럭은 뭔가요?
TDP에서 알 수 있듯이 '열'으로 결정한다. 하지만 데스크탑과 모바일은 조금 다르다.
데스크탑 프로세서는 메인보드 제조사가 따로 있는 경우가 대부분이다. 그리고 메인보드에 따라 성능차이가 있어서 소비자들은 메인보드에 따른 벤치마킹 결과를 참고해서 메인보드를 선택한다. 그렇기 때문에 보틍의 데스크탑 메인보드들은 Fan을 조절해서 TDP제한에 걸리지 않게끔 열을 해소한다.
노트북은 다르다. 메인보드를 노트북 제조사가 만들기 때문에 보통 메인보드가 달라지면 컴퓨터 스펙 자체가 달라진다. 완전한 비교는 어려운 것이다. RAM, SSD 등은 메인보드보다 더 컴퓨터의 성능에 영향을 미친다. 또한 노트북은 배터리가 오래가고 조용하고 가벼워야 한다. 소비자들도 데스크탑에 비해 더 낮은 성능을 감안하고서 가볍고, 조용한 노트북을 구입한다. 성능이 높으면 좋지만 노트북을 고르면서 첫번째 요소가 성능이 되지는 않는다. 그래서 보통의 노트북은 베이스 클럭으로 작동하도록 설계한다.
노트북은 베이스 클럭으로 작동한다는 것은 데스크탑 컴퓨터에 대해 상대적인 의미이다. 노트북이라고 무조건 베이스 클럭으로만 작동하는 것은 아니다. 고성능 노트북이나 쿨링이 뛰어난 노트북은 부스트 클럭으로 작동하는 시간이 길 것이고, 저소음 노트북이나 가벼운 노트북은 부스트 클럭으로 작동하는 시간이 짧을 것이다.(2019.10.29 개정)
위 사진에서 전압을 보자. 사진을 보면 클럭이 오르는데, 소비전력은 크게 오른다. 여기서 관심있게 봐야 할 것은 전압이다. 3.5Ghz까지는 전압이 같은데, 소비전력 증가량이 일정하다. 반면, 3.6Ghz부터 전압이 오르는데, 소비전력도 크게 오른다. 3.9Ghz는 전압도 크게 오른다. 소비전력은 전압에 따라 갈린다고 봐도 될 정도로 전압의 영향을 받는데, 클럭이 높아지면 그 전압도 크게 오른다.
클럭이 높아지면 전압이 크게 높아지는데, 소비전력은 전압의 제곱만큼 증가한다. Clock, 즉 일은 비례적으로 증가하는데 소비전력은 전압의 제곱만큼 증가하니, 그 만큼 에너지 효율이 떨어지고 발열량이 크게 증가하는 것이다. 그러므로 부스트 클럭을 유지한다는 것은 배터리 소모를 크게 늘리고 팬 소음도 커진다는 것이다. 이런 차이 때문에 데스크탑 프로세서는 All Core Boost 또는 Boost Clock을 보면 프로세서의 성능을 알 수 있지만, 노트북은 (용도에 따라 다르지만; 보통은) 베이스 클럭을 봐야 한다.
물론 편법으로 부스트 클럭을 유지할 수는 있다. 하지만 편법이 적용되지 않는 제품도 있고, 편법을 적용했는데도 쿨링 능력이 부족하면 클럭이 떨어질 수 있다. 수동으로 조절해서 사용하고 싶다면 충분히 알아보고 구입해야 한다.
여기까지 읽고 나면 드는 의문이 하나 있다.
그러면 베이스 클럭을 보면 되는 것 아닌가요?
그래서 재미있는 비교군을 가져왔다.
i7-7920HQ : 4 Cores, 3.1Ghz up to 4.1Ghz, TDP 45W i7-7660U : 2 Cores, 2.5Ghz up to 4.0Ghz, TDP 15W i7-7567U : 2 Cores, 3.5Ghz up to 4.0Ghz, TDP 28W i7-7560U : 2 Cores, 2.4Ghz up to 3.8Ghz, TDP 15W
i5-7440HQ : 4 Cores, 2.8Ghz up to 3.8Ghz, TDP 45W i5-7200U : 2 Cores, 2.5Ghz up to 3.1Ghz, TDP 15W
몇 개의 CPU 스펙을 가져왔다. i7끼리, i5끼리 묶었다. i7이 등급이 높지만 성능 순서는 절대 아니다.
그래서 성능 순서로 재 정렬해보면
i7-7920HQ : 4 Cores, 3.1Ghz up to 4.1Ghz, TDP 45W i5-7440HQ : 4 Cores, 2.8Ghz up to 3.8Ghz, TDP 45W
i7-7660U : 2 Cores, 2.5Ghz up to 4.0Ghz, TDP 15W i7-7560U : 2 Cores, 2.4Ghz up to 3.8Ghz, TDP 15W i5-7200U : 2 Cores, 2.5Ghz up to 3.1Ghz, TDP 15W
이렇게 된다. TDP가 같은 것끼리 묶인다.
듀얼코어이면서도 베이스클럭이 굉장히 높아 TDP가 높은 제품이 있다. 좀 더 찾아보면, 쿼드코어이면서 듀얼코어보다 베이스클럭이 낮은 경우도 있다. 이러한 차이를 구분할 필요가 없는 기준이 TDP이다.
쿼드코어 저전력 모바일 프로세서는 뭐가 좋아요?
작년, AMD가 모바일 프로세서 저전력 라인에 쿼드코어를 출시했다. 그리고 인텔도 AMD의 공격적인 제품 구성에 발빠르게 새로운 제품을 내놓았다.
지금까지의 CPU는 듀얼코어 CPU보다 쿼드코어 CPU의 성능이 확실히 좋았기 때문에 AMD가 저전력 라인에 쿼드코어를 출시하니 소비자의 마음이 AMD쪽으로 기울 수밖에 없었다. 그래서 인텔이 급히 저전력 라인에 쿼드코어를 출시하게 된다.
하지만 인텔의 장점은 멀티코어가 아니다. 인텔은 코어당 성능이 굉장히 좋다. 인텔은 2013년에 출시된 하스웰도 4.5Ghz이상으로 오버클럭하는 데에 1.25V이상을 넘지 않았다. 순정 상태의 전압은 말할 것도 없다. 2017년에 출시된 Ryzen은 같은 전압으로는 3.7Ghz정도가 최선이다. 반면에 Multi Core 성능은 인텔의 장점이 아니다. 이전 글에서도 멀티코어 성능에 대해 언급했다. AMD는 비셰라부터 멀티 코어를 지원하는 프로그램에 대해서는 강한 모습을 보여줬다. 라이젠 또한 멀티코어 성능은 인텔보다 좋았다. 이런 양상은 라이젠 이후 출시 된 Intel 8세대 프로세서에서도 나타난다.
AMD Ryzen 5 1600x와 Intel i7-8700k는 베이스 클럭을 보면 거의 비슷한 스펙인 것 같지만 사실은 그렇지 않다. 앞서 말한 것과 같이 인텔은 클럭이 높은 게 장점이다. 같은 TDP를 가지고도 실제 작동 주파수가 0.7Ghz가 높다. (데스크탑 프로세서이므로 Boost Clock을 비교한다.) 라이젠이 출시될 때는 IPC가 인텔에 거의 근접했다고 알려지기도 했었는데, AMD Ryzen 5 1600x와 Intel i7-8700k의 싱글쓰레드 벤치마킹 점수의 차이는 두 CPU의 클럭 차이보다 더 크게 나타났다. 즉, 해당 벤치에서 수행하는 연산에 대해서는 AMD의 IPC가 인텔 8세대 프로세서에 못미친다는 뜻이다. 반면 멀티코어의 점수는 그 격차가 감소했다. 단순계산(단순계산일 뿐이다. 실제로는 다를 수 있다)으로 클럭을 같게 했을 때는 라이젠이 오히려 더 높은 성능을 보여준다.
인텔은 클럭이 높을 때에 유리함에도 불구하고 클럭을 낮추고 쿼드코어를 출시했다. 클럭은 라이젠 프로세서보다 더 낮다. 모바일 라이젠의 최하위 모델인 Ryzen 3 2300u는 Base Clock이 2.0Ghz이고 Boost Clock이 3.4Ghz이다. 최상위 모델인 Ryzen 7 2700u는 Base Clock이 2.2Ghz이고 Boost Clock은 3.8Ghz이다. 인텔은 최하위 모델인 i5-8250u는 Base Clock이 1.6Ghz이고 Turbo Clock이 3.4Ghz이다. 최상위 모델인 i7-8650u는 Base Clock이 1.9Ghz이고 Turbo Clock은 4.2Ghz이다.
이번 인텔 8세대 모바일 프로세서의 장점은 Turbo Clock이다. 그리고 넓은 주파수 범위(Frequency Range)에 있다. 인텔이 지금까지 Dual Core를 판매한 것은 장점이 있기 때문이다. 멀티 쓰레드를 지원하지 않는 프로그램에서는 클럭이 높은 게 유리하기 때문이다. 아직까지도 멀티코어를 지원하지 않는 프로그램이 있는데, 그런 프로그램에서 3.8Ghz이상을 요하는 프로그램도 봤다. 인텔은 Turbo Clock을 4.0Ghz로 만들었다. 멀티 쓰레드를 지원하지 않는 프로그램에서 인텔의 장점을 살려 4.0Ghz로 작동하면서, 높은 클럭으로 생긴 열을 낮은 베이스 클럭으로 보상할 수 있다. 클럭이 낮으면 열효율이 증가하기 때문에 성능을 더 높게 오래 유지할 수 있다. 라이젠은 반대로 베이스 클럭을 높여서 멀티코어를 지원하는 프로그램에 대해 높은 성능을 내도록 구성했다.
HQ모델을 기대하지는 말자
이 글을 통해 꼭 하고 싶었던 말인데, 열이 제대로 해소된다면 분명히 i5-8250u는 쿼드코어의 퍼포먼스를 보여줄 것이다. 컴퓨터 부팅, 웹서핑, 문서편집 등은 쿼드코어의 퍼포먼스를 보여줄 것이다. 하지만 보통의 쿼드코어 시스템에서 기대하는 동영상 렌더링, 프로그램 컴파일, 게임 플레이는 계속적으로 발열이 생기게 되고 TDP에 따라 클럭이 감소할 것이다. 아이러니(?) 하게도 i5-8250u는 쿼드코어의 퍼포먼스를 보여줄 것이지만, 쿼드코어에서만 원활하게 이용 가능한 프로그램을 구동할 때는 쿼드코어의 성능을 기대할 수 없다. 웹서핑이나 간단한 문서작업은 게이밍 PC만큼 빨라질 것이지만, 게임은 할 수 없다. 그러니 고성능의 노트북이 필요한 것이라면 저전력 제품을 구입하진 않아야 한다.
It is a part of the world's Ryzen users to wonder about, and there are many people who do not yet know it, so I write in English.
Nessesity
CnQ or SS is a technology that saves power by lowering voltage and clock. Since power consumption is proportional to the clock and is proportional to the square of the voltage, when CnQ is used, it must be lowered to not only the clock but also the voltage. Most overclockers do not use Cool'n'Quiet or Speed Step. This is because overclocking is for better performance, but using CnQ or SS will reduce performance. However, if you can fine-tune the power options in Windows, you can achieve maximum performance with CnQ or SS. The performance is lower than when you do not use CnQ or SS, but you can enjoy the effect of overclocking and the power saving / thermal management effect of CnQ or SS when not using for a long time. Moreover, in today's 8-core systems, there may be cores that do not work according to the game's optimization level. You can save power even during the game. I tend to turn on the computer for a long time, so I prefer to turn on CnQ or SS even if I overclock it.
Intel
But there is a problem. I do not know if this is a problem with Ryzen, but I could not turn on CnQ just like Intel. Intel was not difficult to overclock while SS turned on.
If you set the CPU Vcore Voltage Mode to Adaptive Mode like in the above picture, the overclock will be set to the user defined voltage only at the highest clock, and the lower clocks where Speed Step operates, the default voltage is applied.
Ryzen
But Ryzen is different.
In the above picture, only the Auto, Offset Mode, and Fixed Mode are available in CPU Vcore Volate setting.
With Offset Mode, the voltage compensation(Offset-ting) will be applied even at low clocks where CnQ is operates. If you overclock at a high voltage, the voltage will be high even if CnQ is activated.
Fortunately, Ryzen can change each Pstate.
Here you only need is to increase the voltage and clock of the highest clock(Pstate0). This is not difficult because it is the same process as general overclocks that do not use CnQ.
I wouldn't write post if turning CnQ on is finished like this.
The problem is that when changing Pstate0 in the BIOS, the Pstate0 state will not be reached if it is higher than the "default voltage".
When CnQ is off, it is ok to raise the voltage of Pstate0 at random, but when CnQ is on, if the voltage is higher than the "default voltage", the CPU state transition will not made to the Pstate.
"Default voltage" for Ryzen 1700 is 1.18750 V. A 3.6Ghz model, such as 1600 or 1700X, is supposed to be 1.35V.
So, in Pstate0, set to the "defaul voltage". In Offset Mode, increase the overall voltage to increase the voltage of Pstate0.
It then decrease the voltage of the other Pstate to make it the original voltage.
Full Work
So I will try to CnQ to fully work with using both voltage offset and custom Pstates functions.
Not surprisingly, overclocking stabilization should be done with SS or CnQ turned off, whether Intel or AMD.
Remember tabilized values. My Ryzen was stabilized at the clock of 3.775Ghz at 1.3V.
Overclock
Now, go to the Custom Pstates settings in Bios.
The voltage I need is 1.3V, but I set a voltage to the "default voltage" which is 1.18750V. I need additional 0.11250V to stabilize the CPU.
Now, Compensate(Offset) Voltage.
Set the voltage here to Offset Mode and add 0.11250 voltage. Now Pstate0 is 3.3775Ghz and is 1.3V
Change voltage of other Pstates.
Now re-compensate(re-offset) the voltage at the lower clock which CnQ is operates. Enter the Custom Pstates setup screen again.
Here, subtracts the voltage of Pstate1 and Pstate2 by 0.11250.
In my case I overclocked Pstate1. and I undervolted Pstate2.
3.6Ghz models, 4.0Ghz models have different defaults for Pstate1 and Pstate2.
Therefore, do not compare with my clock / voltage.
This will increase the voltage only at the maximum clock while using CnQ.
Wrap-Up
As I mentioned in the introduction, there are performance differences depending on power options.
Refer to the following article to minimize the performance degradation(Korean only)
AMD's motherboards include AMD Generic Encapsulated System Architecture (AGESA) software in the Bios. In the Custom Pstates setting, it is an option of AGESA. If it is higher than the basic voltage of the CPU, it will not reach to that state. But think about whether it is possible to give a higher voltage by using offset because it is a voltage control option of motherboard itself. So there is separate software for the CPU in Bios, which seems to work separately from the mainboard Bios software. This is my guess, but it seems to be the most reasonable guess.
If the task manager displays the clock set by Pstate0 at the "Base speed", but the CPU does not actually change the state to the Pstate0 while heavy loading, then should follow the above steps.
The Custom Pstates function is included in all x370 and b350 boards because it is an AGESA function(I guess), and you should check the a320 board. Offset Mode is definitely supported on Asrock and Asus boards. Gigabyte has a feature called Dynamic Vcore. It seems to be the same function.
Biostar has comfirmed that is does not support Offset Mode.
