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만큼 빨라질 것이지만, 게임은 할 수 없다. 그러니 고성능의 노트북이 필요한 것이라면 저전력 제품을 구입하진 않아야 한다.
Merlin 펌웨어는 Stock(정식)펌웨어를 기반으로 만들어져 있습니다. 때문에 정식 펌웨어가 업데이트되면 멀린 펌웨어는 정식 펌웨어를 통합합니다. 정식 펌웨어의 기능을 대부분 담고 있으니 정식 펌웨어에서도 참고할 수 있을 듯합니다.
최적화
HW NAT
제가 커스텀 펌웨어를 쓰지 않으려고 했던 이유는 하드웨어 가속을 지원하지 않아서였습니다. HW NAT은 200Mbps이상의 기가인터넷에서는 필수입니다.
하지만 ASUS의 경우, 정식펌웨어와 멀린 펌웨어도 HW NAT을 사용하려면 조건이 있습니다.
ASUS Router의 HW NAT은 두 가지가 있습니다.
CTF only 와 CTF+FA입니다. 정식 펌웨어에서는 Level 1, Level 2로 표현됩니다.
CTF (Cut Through Forwarding): 넷 가속을 위한 소프트웨어 최적화 FA (Flow Accelerator): DHCP 또는 고정 IP 유선 연결을 위한 하드웨어 넷 가속 메커니즘
제가 500Mbps환경에서 사용해보니 CTF만 되어도 충분한 속도가 나옵니다.
순정 펌웨어 HW NAT기능표
종류
기능
메뉴
하드웨어 가속
QoS
Traditional
Adaptive Qos->QoS
미지원
QoS
Adaptive
Adaptive QoS->QoS
Level 1
LAN
Spanning-Tree Protocol
LAN->Switch Control
Level 1
해당 없음
Level 2
멀린 펌웨어 HW NAT 기능표
종류
기능
메뉴
하드웨어 가속
QoS
Traditional
Adaptive Qos->QoS
Off
Traffic Monitor
IP Traffic Monitoring
Tools->Other Settings
Off
QoS
Adaptive
Adaptive QoS->QoS
Level 1
해당 없음
Level 2
*이번 편은 포스트 번역 및 요약이기에 최대한 원형을 유지했습니다.
*이 외에도 하드웨어 넷을 꺼야 하거나, Level 1만 사용해야 하는 기능이 있습니다. AI Protection, Traffic Analyzer가 이에 해당합니다.
무선
General
Wireless Mode : 무선에 사용할 모드를 선택한다. 2.4Ghz는 Turbo QAM을 사용하려면 Auto로 두어야 한다.
Control Channel : 채널 번호를 선택한다. 항상 Manual로 두고 전파 혼신을 막기 위해 주변 라우터에서 사용하지 않는 채널을 선택한다. 단, 5Ghz 채널 165는 저성능의 채널이니 피한다.
Protected Management Frames : 802.11 표준에서 지원하는 보호 모드이다. 보안성은 올라가지만 호환성은 떨어진다. 아이폰, 아이패드는 연결되는데 맥북 프로는(2016년형) 연결이 안된다. 추천 값 : Disable 또는 Capable로 둔다.
Group Key Rotation Interval : WPA그룹 키를 갱신하는 주기를 입력한다. 키를 갱신하는 동안 연결이 끊기거나 불안정해질 수 있다. 추천 값 : 0 또는 259200 필자 추천 : 1800(기본 값): WPA 인증 및 보안의 기초가 그룹 키를 통해 이루어진다. (2019.01.09개정)
WPS
보안성이 떨어지니 끈다.
Professional
고급 설정은 개인적인 경험을 다수 반영하여 출처 게시글과는 매우 다름에 유의(2019.01.09 고급 설정 전면 수정)
2.4Ghz
2.4Ghz는 신호 거리가 길고 속도가 느린 게 특징이다.
Roaming assistant : 신호가 약해지면 연결을 끊는다. 여러 개의 라우터를 사용할 때 신호가 약한 방에서 다른 라우터로 자동으로 연결되지 않을 때에 자동으로 다른 라우터로 연결되도록 하려면 사용한다.
Bluetooth Coexistence : 최근 추가된 옵션으로 보인다. 블루투스와 와이파이 모두 2.4Ghz로 작동하기 때문에 서로 혼신의 가능성이 있는데, 이걸 줄여주는 옵션이다. 주변 블루투스 연결이 끊기면 활성화 한다.
_Enable_을 선택하면 주변 블루투스 장비와 협상하여 스펙트럼을 공유한다. _Preemptive_를 선택하면 블루투스 장치에 현재 라우터에서 사용하는 채널을 점유 중이라고 알린다. Pre-emptive모드에서는 TX-Burst모드를 지원하지 않는다. 이 기능은 블루투스 장치가 cooperate모드를 지원해야 한다.
추천 값 : Disable ; 주변 블루투스 장치가 끊기지 않으면 끈다. Pre-emptive를 우선 시도하고, 개선되지 않으면 coexistence를 켠다. 그래도 개선되지 않는다면 끈다.
Enable IGMP Snooping : 멀티캐스트 트래픽을 감시하고 IGMP를 지원한다. 라우터가 멀티캐스트 트래픽 데이터를 받으면 라우터에 연결된 모든 클라이언트에 멀티캐스트 트래픽을 보낸다. 여기서 IGMP Snooping을 통해 멀티캐스트 트래픽을 받을 클라이언트를 선택한다. 출처 글에서는 스트리밍이나 미러링 할 때에 활성화하라고 하지만 필자는 비활성화를 추천한다. 멀티캐스트는 특정 IP대역에 송출된 데이터를 말하는데 흔히 생각하는 스트리밍(동영상, 음악 스트리밍)이나 미러링(화면 미러링)은 멀티캐스트 IP대역에 송출하는 것이 아니다. 참고 : 위키피디아(멀티캐스트는 보통 IP 멀티캐스트 형태로 구현), 스윗가든리서치 그룹(블로그) (이미지 참고) 추천 값 : Disable
Preamble Type : CRC블럭의 타입을 설정한다. CRC블럭은 무선으로 송 수신한 데이터의 무결성을 체크한다. Long을 선택하면 호환성과 커버리지가 증가하고, Short를 선택하면 성능이 증가한다. 추천 값 : Long ; 2.4Ghz는 높은 성능을 위한 주파수가 아니므로 안정적인 연결이 가능한 Long을 선택한다.
AMPDU RTS : 통신 오류 조절을 개선한다. 추천 값 : Enable ; 2.4Ghz는 더 넓은 커버리지(신호가 약한 곳)에서 사용하기 위한 주파주이므로 활성화한다.
Enable TX Bursting : TX Bursting을 사용한다. b/g장치에서 더 높은 성능을 낸다. 추천 값 : Disable ; 요즘 2.4Ghz장비는 N모드를 사용한다. b/g 장치는 장치가 느리기 때문에 b/g를 위한 특별한 기능으로 리소스를 사용할 필요 없다. 껐을 때에 게임 딜레이가 감소한다는 후기가 많다.
Enable WMM APSD : 모바일 장치의 전력관리에 도움이 된다. 추천 값 : Enable
Reducing USB 3.0 Interferance : 2.4Ghz에서 더 넓은 커버리지와 성능을 낸다. 추천 값 : Disable ; USB 3.0장치를 사용하면 비활성화. 높은 성능은 5Ghz에서 필요하므로 USB 3.0위주로 설정한다.
Optimize AMPDU aggregation : AMPDU가 많으면 오류 핸들링 능력이 상승한다. 성능이 감소한다. 간섭이 많은 지역에서 사용한다. 추천 값 : Disable ; 2.4Ghz는 과포화 상태이다. 오류 핸들링을 위한 AMPDU 패킷은 많을 수록 좋다.
Optimize ack suppression : 에러를 확인할 수 있는 패킷을 줄인다. 와이파이 클라이언트의 에러 검출 결과를 기다리지 않고 다음 데이터를 전송한다. 에러가 조금이라도 있다면 Disable 추천 값 : Disable ; 위와 같은 이유. 과포화 상태이므로 혼선이 많다. 오류 검출 패킷은 많을수록 좋다.
Turbo QAM : 지원하는 클라이언트에서 높은 성능을 보여준다. 추천 값 : Enable
Airtime Fairness : 신호가 약한 장치를 희생하고 성능을 높인다. 추천 값 : Enable ; 신호가 약한 곳에서 고성능을 필요로 할 때에는 Disable
Explicit Beamforming : 빔포밍을 지원하는 장치에서 빔포밍을 사용한다. 추천 값 : Enable ; 애플 기기는 호환 문제가 있다고 하지만 그래도 더 좋은 성능을 보여준다. Macbook Pro 15 (2016), iPad Pro 9.7 1세대, iPhone 6s Plus에서 호환 문제는 없었다.
Universal Beamforming : 빔포밍을 지원하지 않는 장치에서 빔포밍을 사용한다. 추천 값 : Enable ; 애플 기기는 호환 문제가 있다고 하지만 그래도 더 좋은 성능을 보여준다.
Tx power adjustment : 출력 크기이다. 최대치로 둔다. 추천 값 : 최댓값; 필자는 발열문제도 있고, 호기심에 출력제한을 없앤 펌웨어를 올려서 규제에 맞게 낮춰서 사용한다.
5GHz
5Ghz는 신호 거리가 짧고 속도가 빠르다.
Roaming assistant : 신호가 약해지면 연결을 끊는다. 여러 개의 라우터를 사용할 때 신호가 약한 방에서 다른 라우터로 자동으로 연결되지 않을 때에 자동으로 다른 라우터로 연결되도록 하려면 사용한다.
또는 5Ghz와 2.4Ghz의 SSID가 같아서 멀어지면 자동으로 2.4Ghz로 전환되게 하고 싶어도 사용한다.
Enable IGMP Snooping : 멀티캐스트 트래픽을 감시하고 IGMP를 지원한다. 라우터가 멀티캐스트 트래픽 데이터를 받으면 라우터에 연결된 모든 클라이언트에 멀티캐스트 트래픽을 보낸다. 여기서 IGMP Snooping을 통해 멀티캐스트 트래픽을 받을 클라이언트를 선택한다. 출처 글에서는 스트리밍이나 미러링 할 때에 활성화하라고 하지만 필자는 비활성화를 추천한다. 멀티캐스트는 특정 IP대역에 송출된 데이터를 말하는데 흔히 생각하는 스트리밍(동영상, 음악 스트리밍)이나 미러링(화면 미러링)은 멀티캐스트 IP대역에 송출하는 것이 아니다. 참고 : 위키피디아(멀티캐스트는 보통 IP 멀티캐스트 형태로 구현), 스윗가든리서치 그룹(블로그) (이미지 참고) 추천 값 : Disable
Beacon Interval : 라우터가 있다는 신호를 보내는 주기를 선택한다. 추천 값 : 1000(최대) ; 성능 개선이 있다. 호환성 문제가 있다면 기본값인 100을 사용한다. 필자는 다른 공유기와 전환하는 데에 문제가 있어서 애매한 값인 800을 사용한다.
AMPDU RTS : 통신 오류 조절을 개선한다. 추천 값 : Disable ; 5Ghz는 더 높은 성능을 위한 연결이므로 비활성화한다.
Enable TX Bursting : TX Bursting을 사용한다. b/g장치에서 더 높은 성능을 낸다. 추천 값 : Disable ; 5Ghz에는 왜 있는지 모르겠으나 성능 차이는 없는 것 같다.
Enable WMM APSD : 모바일 장치의 전력관리에 도움이 된다. 추천 값 : Enable
Optimize AMPDU aggregation : 오류 핸들링 능력이 상승한다. 성능이 감소한다. 간섭이 많은 지역에서 사용한다. 추천 값 : Enable ; 채널을 수동으로 잡아줬으니 간섭은 많지 않을 것이다.
Optimize ack suppression : 에러를 확인할 수 있는 신호를 줄인다. 와이파이 클라이언트의 에러 검출 결과를 기다리지 않고 다음 데이터를 전송한다. 에러가 조금이라도 있다면 Disable 추천 값 : Enable ; Roaming Assistant로 신호가 강한 곳에서만 사용하도록 한다면 사용해보자.
Airtime Fairness : 신호가 약한 장치를 희생하고 성능을 높인다. 추천 값 : Enable ; 신호가 약한 곳에서 고 성능을 필요로 할 때에는 Disable
Explicit Beamforming : 빔포밍을 지원하는 장치에서 빔포밍을 사용한다. 추천 값 : Enable ; 애플 기기는 호환 문제가 있다고 하지만 그래도 더 좋은 성능을 보여준다. Macbook Pro 15 (2016), iPad Pro 9.7 1세대, iPhone 6s Plus에서 호환 문제는 없었다.
Universal Beamforming : 빔포밍을 지원하지 않는 장치에서 빔포밍을 사용한다. 추천 값 : Enable ; 애플 기기는 호환 문제가 있다고 하지만 그래도 더 좋은 성능을 보여준다.
Tx power adjustment : 출력 크기이다. 최대치로 둔다.
추천 값 : 최댓값; 필자는 발열문제도 있고, 호기심에 출력제한을 없앤 펌웨어를 올려서 규제에 맞게 낮춰서 사용한다.
유선
Switch Control
Enable Jumbo Frame : 더 큰 프레임을 보낸다. 점보프레임을 지원하지 않는 장치에서는 오히려 성능이 감소할 수 있다. 추천 값 : Disable
NAT Acceleration : 하드웨어 가속을 켠다. 끄면 Traffic Monitor가 정확해진다. 추천 값 : Auto
Spanning-Tree Protocol : 라우터 하위 컴퓨터의 구조를 파악하는 신호를 보내고 컨트롤한다. 라우터 아래에 있는 스위치가 있는 구조라면 데이터의 루프를 피하고, 최단 루트를 선택하는 데에 도움을 준다. 참고자료 : netmanias, snbforums 추천 값 : Disable ; 출처 포스트에서는 하위에 Switch가 있으면 활성화하라고 하지만 필자가 보기에는 루프구조만 아니면 필요 없다.
저는 원래 ipTIME공유기만 사용했습니다. 인터넷도 안정적이고 AS가 간편했기 때문인데요. 원래 사용하던 공유기가 고장나서 쇼핑을 하던 중에, 지인으로부터 ASUS 리퍼비시 공유기를 싸게 구입할 수 있다는 걸 알게 되었습니다. 그것이 바로 T-mobile용 라우터. 하드웨어 자체는 ASUS RT-AC68U와 같다고 하여 ASUS에 대한 믿음과 기대로 구입했습니다.
원래는 T-mobile 정식 펌웨어를 사용하려고 했습니다.어차피 AC68U와도 펌웨어도 비슷할 것이고, Hardware NAT을 지원하지 않는 커스텀 펌웨어는 기가인터넷 환경에서 오히려 역효과를 가져올 것이라는 판단 때문입니다.
하지만 몇몇 문제가 있었습니다. 그 중 하나가 Port Forwarding. 전에 사용하던 공유기는 Port Forwarding 갯수에 제한이 없었는데, ASUS는 32개로 제한되어 있었습니다. 64개여도 참고 쓸만 한데, 32개라니... NAS를 외부에서 접속하려면 반드시 Port Forwarding을 해야 하는데, 이용하는 서비스(서버)가 많으면 더 많은 Port Forwarding을 해야 합니다.
커스텀 펌웨어는 128개까지로 늘어납니다.
<Port Forwarding 제한이 128개로 늘어납니다>
또 다른 이유는 업데이트입니다. 살 때도 RT-AC68U에 비해 업데이트가 느리다는 것을 알고 있었는데, UPnP를 켜도 NAS에서 UPnP라우터로 인식하지 못해서 포트별로 수작업으로 Port Forwarding에 등록 해줘야 했습니다. 게다가 NAS에 서비스를 추가할 때마다 Port Forwarding을 해줘야 했죠. 그래서 다른 펌웨어가 필요해졌습니다.
여기에 라우터의 펌웨어를 바꾸도로 불을 지피는 게 있었으니, 정식 펌웨어를 기반으로 하는 Merlin 펌웨어는 Hardware NAT을 지원한다는 것!
그래서 큰 맘 먹고 ASUS 펌웨어를 올려봤습니다.
펌웨어 변경을 시작하기 전에
이 글은 최근 T-mobile용 라우터를 구입하여 최신 펌웨어인 3.0.0.4.376_3181이 설치된 라우터에 ASUS 펌웨어를 설치하는 글이다.
3181버전(아마도 이전 몇개 펌웨어를 포함해서)은 리셋버튼을 누르고 전원을 켠다고 CFE miniWeb Server페이지에 접속되지 않는다. 다만 필자가 보기엔 앞으로도 CFE miniWeb Server에 접속하는 방법이 바뀔 뿐, 못들어가게 막진 않을 것이다.
<RT-AC68U라고 나온다>
리퍼비시를 구입했더니 SSH접속만 했을 뿐인데 RT-AC68U라고 나온다. 이전에 사용하던 사람이 RT-AC68U펌웨어를 올려놓고 사용했던 것 같다. 그리고 리퍼비시 중에는 이러한 라우터가 꽤 많을 것으로 보인다.
라우터 초기화 및 ASUS펌웨어 설치에 필요한 파일 다운로드
무작정 따라하기 쉽게 라우터를 초기화 한다. 라우터 설정 페이지에 초기화가 있다. 오프라인으로 작업해야 하니 모든 파일은 미리 다운로드 한다.
파일 다운로드 하기 : 10MB까지만 첨부가 가능해서 다운로드 링크를 올립니다. 앞으로의 작업에서 라우터 전원 케이블과 컴퓨터에 연결하는 LAN케이블 외의 케이블은 모두 라우터에서 제거한다.
출처 : http//blog.naver.com/inviewfinder/220914723102 펌웨어 설치는 기본적으로 위 블로그를 따라간다.
SSH를 지원하는 펌웨어로 다운그레이드
라우터의 펌웨어를 변경하려면 ASUS프로그램이 RT-AC68U로 인식할 수 있어야 한다. 그러기 위해 부트로더를 변경해야 한다.
1. NVRAM 초기화
라우터 끄기. 옆면의 WPS버튼을 누른 상태로 공유기 켜기. 전원 LED가 깜빡거리면 WPS버튼에서 손 떼기. 전원과 LAN LED가 켜질 때까지 기다리기.
2. CFE 모드 진입
웹 브라우저 주소창에 192.168.29.1를 미리 입력하기. 라우터 끄기. Reset, WPS, Wifi Off 버튼을 모두 누른 채로 라우터 켜기. 10초 정도 후에 WPS, Wifi Off 버튼에서 손 떼기. (Reset버튼에서 손이 떨어지지 않게 주의!) 192.168.29.1에 접속하기.(Reset버튼을 누른 상태여야 합니다)
저는 이 단계에서 고생을 많이 했습니다. 백신을 끄고 하니 그제서야 인식이 되었습니다. 혹시 잘 안되는 분은 백신이나 기타 네트워크 감시 프로그램을 끄고 해보시면 될겁니다.
CFE miniWeb Server에서 Browse 버튼 누르기.(Reset버튼을 누른 상태여야 합니다) 파일 선택 팝업창에서 첨부파일\ASUS\Work\AC1900안에 있는 .trx파일 선택하기.(Reset버튼을 누른 상태여야 합니다) 업로드 누르기.(Reset버튼을 누른 상태여야 합니다)
웹브라우저가 웹 탐색을 시작하면 Reset버튼에서 손을 뗀다.
Reset에서 손을 떼야 업로드 성공 메시지가 출력됩니다.(Reset을 누르고 있으면 펌웨어 업로드가 끝나지 않고 실패 합니다.)
SSH 활성화
라우터 설정 페이지 접속. Administration(관리) 클릭. System(시스템) 클릭. SSH Enable(SSH 활성화) YES에 체크
Apply(적용)
CFE 부트로더 변경 준비
출처 블로그에서는 고정 IP를 할당하지만 그럴 필요는 없다. 지금 라우터는 부팅이 완료된 상태인데, 부팅이 완료된 상태에서는 DHCP서버가 실행되기 때문에 공유기와 통신하는데 문제가 없다.
1. Putty 실행
첨부파일 \ASUS\putty.exe 실행
Host Name에 12.168.29.1 입력 Port는 22, Connection type은 SSH이고, 기본으로 입력되어 있다. Open을 클릭하여 SSH서버에 접속한다. 몇 가지 인증과 보안에 관한 경고창이 뜨는데, 모두 Yes를 클릭한다.
서버에 연결되면 검은 창에 login as: 가 나타난다. 계정은 admin이고 비밀번호는 password이다 : 비밀번호는 보이지 않으니 창에 변화가 없어도 그냥 입력하면 된다.
이렇게 뜨면 로그인 성공
2. WinSCP 실행
첨부파일 \ASUS\WinSCP-5.11.3-Portable\WinSCP.exe 실행
File protocol : SCP : putty는 프로토콜을 바꿀 필요가 없었지만 WinSCP는 반드시 바꿔줘야 한다. Host name : 192.168.29.1 User name : admin Password : password
위 정보를 모두 입력하고 Login 클릭 여기서 뜨는 보안 경고 창에서도 Yes 클릭
3. 설명을 편하게 하기 위해 Interface 변경
기본 모드를 이용해도 문제 없지만, Drag & Drop이 안된다.
Options Preferences...
Environment -> Interface Commander 선택 OK
WinSCP 다시 실행하고 라우터에 로그인 왼쪽 Pane(창, 영역)에 첨부파일\ASUS\Work가 보이도록 Navigate(이동)한다.
CFE 부트로더 변경
라우터에서 기존의 부트로더를 꺼낸다. 기존의 부트로더에서 라우터의 고유 데이터를 새로운 부트로더에 복사한다. 그리고 새 부트로더를 라우터에 저장한다.
1. 부트로더 백업
라우터에 접속한 Putty에 다음 명령 입력
cat /dev/mtd0 > original_cfe.bin
잠시 후 에러메시지 없이 admin@ (none) : /tmp/home/root#이 뜨면 성공
WinSCP에서 오른쪽 Pane에 있는 original_cfe.bin을 왼쪽 Pane으로 드래그한다.
2. 새 부트로더 수정
Windows Explorer(탐색기)로 첨부파일\ASUS\Work\AC68U로 이동 rt-ac68u_1.0.2.0_us.bin을 첨부파일\ASUS\Work로 복사 rt-ac68u_1.0.2.0_us.bin의 이름을 new_cfe.bin으로 이름바꾸기
첨부파일\ASUS\Work폴더로 이동하고 아래 파일이 모두 있는지 확인
cfe.exe new_cfe.bin original_cfe.bin
cfe.exe 실행
검은 창이 나타났다가 new\_cfe.bin.bak파일이 생기는지 확인
3. 새 부트로더 라우터로 복사
new_cfe.bin과 mtd-write 파일을 라우터에 복사 왼쪽 Pane에서 new_cfe.bin과 mtd-write를 드래그해서 오른쪽 Pane에 드랍한다.
4. 라우터에 업로드 한 파일 확인
putty에서 ls -l입력
mtd-write
original_cfe.bin
new_cfe.bin
이 출력돼야 함
grep mac ./original_cfe.bin ./new_cfe.bin
아래 사진과 같이 하얀 부분의 값이 같아야 합니다.
<경고창이 없어야 합니다. 순서를 헷갈리면서 오류가 있는 스크린샷만 남았습니다.>
5. 라우터의 부트로더에 새 부트로더 설치
putty에서 chmod u+x mtd-write 입력 오류 없이 다음 줄에 #이 나와야 합니다.
./mtd-write -i new_cfe.bin -d boot 오류 없이 다음 줄에 #이 나와야 합니다.
reboot 라우터가 다시 시작 되면서 위의 사진처럼 서버가 닫혔다는 오류가 나타납니다.
출처 블로그에서는 버전 확인 방법을 알려줬지만, NVRAM 리셋까지 해야 변경된 버전이 적용되기 때문에 생략합니다.
ASUS 펌웨어 설치
이제 펌웨어 설치만 하면 정식 펌웨어이든, RT-AC68U를 지원하는 커스텀 펌웨어든 뭐든 설치할 수 있다.
1. NVRAM 초기화
라우터를 끈다. 옆면의 WPS버튼을 누른 상태로 공유기를 켠다. 전원 LED가 깜빡거리면 WPS버튼에서 손을 뗀다. 전원과 LAN LED가 켜질 때까지 기다린다.
2. ASUS 펌웨어 설치
미리 ASUS 펌웨어 복구 프로그램을 실행하고 RT-AC68U 펌웨어를 선택해둔다.
라우터를 끄고 Reset 버튼을 누른 상태로 전원을 켠다. 전원 LED가 느리게 깜빡거리면 Rescue모드로 진입 된 것이지만, 20초 이상 Reset버튼을 누르고 있는 것을 추천한다.
ASUS 펌웨어 복구 프로그램에서 Upload를 클릭한다. 저는 ASUS 라우터를 두개를 샀는데, 하나는 펌웨어 업로드가 쉽게 되었던 반면 다른 하나는 펌웨어 업로드가 쉽게 되지 않았습니다.
네트워크 감시 프로그램을 끈다 Rescue 모드에 진입할 때 전원 LED가 깜빡거리면 Reset 버튼을 바로 뗀다 IP를 고정한다
저는 반대로 192.168.1.8로도 안되었던 것이 라우터를 부팅하고 DHCP 서버로부터 할당받았던 IP로 고정해주니 잘 되었습니다.
MTD5 파티션 수정하기!
(롤백 방지 및 최신 펌웨어 설치)(2019.01.09 추가) 꽤 오래 전에 나온 팁인데 어째서 이제야 발견했는지 모르겠다..ㅠㅠ
리눅스 사용자는 Windows 사용자들 보다는 커맨드를 사용한 프로그램 실행이 익숙할 것입니다. 리눅스에서는 커맨드의 비중이 비교적 큽니다. 그 중 셸 스크립트는 여러 커맨드를 연속으로 실행할 수 있게 해줍니다. 이러한 스크립트를 Linux가 부팅될 때 실행하도록 할 수 있습니다.
이 글은 Plex Server에 Google Drive를 마운트하는 강좌에서 연결되는 글이므로 Plex 위주로 설명합니다.
스크립트 만들기
커맨드도 텍스트이기 때문에 스크립트도 텍스트로 만듭니다.
파일 확장자는 .sh입니다.
첫 줄은 항상 #!/bin/bash 로 시작합니다.(사용하는 터미널에 따라 다를 수 있습니다.)
커맨드의 끝에 &을 넣으면 명령이 끝나기를 기다리지 않습니다.
예시
#!/bin/bash
bash /home/KollHong/rclone.sh &
반복문이 포함 된 스크립트를 실행하려고 한다고 가정할 때, &을 넣지 않으면 해당 스크립트가 끝나지 않기 때문에 다음 스크립트가 실행되지 않습니다. 보통 #은 실행하지 않는 주석 표현입니다. 하지만 #!는 실행파일이라는 것을 명시하는 표현입니다.
스크립트에서 실행하는 /home/KollHong/rclone.sh는 아래와 같습니다.
#!/bin/bash
while :
do
MOUNTTYPE=\`cat /proc/mounts | grep /home/KollHong/rclone/GoogleDrive | awp '{ print $3 }'
if \[ $MOUNTTYPE \] && \[&MOUNTTYPE = "fuse.rclone" \]
then echo '>> already mounted']
else
rclone mount kollhong: --allow-other --default-permission --no-modtime --writeback-cache -q /home/KollHong/rclone/GoogleDrive &
ls /home/KollHong/rclone/GoogleDrive/
fi
sleep 60
done
while문은 반복문 입니다. 조건을 넣지 않으면 무한 반복합니다. do 이하에서는 마운트되었는지 확인하고, else 이하에서는 마운트를 합니다. PlexDrive에서는 ls를 한 번 해야 한다고 해서 ls문도 넣었습니다. 혹시 마운트 해제될 때를 대비하여 60초 동안 쉬고 다시 반복합니다.
Windows 에서의 시작 프로그램 폴더와 비슷한 방식입니다. Windows 에서 시작 프로그램 폴더에 프로그램을 넣어두면 부팅시에 프로그램이 함께 실행됩니다. 이 때, 보통은 프로그램 자체를 시작 프로그램 폴더에 넣지 않고 프로그램 바로가기를 시작 프로그램 폴더에 넣습니다.
리눅스도 마찬가지 입니다. 리눅스도 Windows 의 시작 프로그램 폴더와 같은 디렉토리가 있습니다. 그 디렉토리가 /etc/init.d입니다.
Windows에도 읽기/쓰기 권한을 변경할 수 있습니다. 보통은 적절하게 권한이 주어지기 때문에 Windows에서는 권한을 변경하는 일이 거의 없습니다.
하지만 MacOS나 Linux에는 실행 권한이 따로 있습니다. 디렉토리의 경우는 실행 권한이 있어야 하위 디렉토리와 파일들을 확인할 수 있습니다. 그렇기 때문에 디렉토리는 기본적으로 실행 권한이 주어집니다. 파일의 경우는 실행 권한이 있어야 터미널에서 실행할 수 있습니다. 터미널에서 실행하는 프로그램/스크립트는 실행 권한이 있어야 합니다. 하지만 파일의 경우 보안을 위해 기본적으로는 실행 권한이 주어지지 않습니다.
권한 설정
터미널에서 실행할 모든 프로그램은 실행 권한을 주어야 합니다.
chmod 755 ~/plexdrive
chmod 755 ./run.sh
~는 홈 디렉토리 입니다. 필자의 경우는 /home/KollHong입니다. .는 현재 디렉토리 입니다. 기본 값은 홈 디렉토리 입니다. pwd 명령을 통해 현재 디렉토리의 위치를 알 수 있습니다.
755는 권한입니다. 첫째 칸은 소유자(Owner), 두번째 칸은 그룹(Group), 세번째 칸은 다른 사용자(Others)에 대한 권한을 나타냅니다. 여기서 그룹은 소유자가 포함된 그룹입니다.
권한은 읽기/쓰기/실행 세 가지 권한이 있습니다. 영어로 표현할 때는 r (Read), w (write), x(execute)로 표현합니다. 숫자로는 r=4, w=2, x=1를 각각 더한 값으로 표현합니다.
읽기/쓰기/실행 모든 권한을 가질 때는 숫자로는 7, 영어로는 rwx로 표현합니다.
읽기/실행 권한만을 가질 때는 숫자로는 5, 영어로는 r-x로 표현합니다.
다음 명령으로 plexdrive 의 권한을 변경합니다. 소유자는 모든 권한을, 그룹과 다른 사용자는 읽기/실행 권한만 갖게 됩니다.
chmod 755 ~/plexdrive
영어 표현은 ls 명령을 입력하면 볼 수 있습니다.
ls -l ~/plexdrive
plexdrive에 rwxr-xr-x를 권한이 주어진 것을 확인할 수 있습니다.
권한 추가
chmod a+x ~/plexdrive
chmod u+x ~/plexdrive
755나, 644와 같은 숫자 대신 문자와 +기호를 사용했습니다.
a+x는 모든 사용자에게 x(eXecute)권한을 주는 것이고, u+x는 유저에게 x권한을 주는 겁니다.
반대로 a-x도 가능하겠죠?
저는 보통 시스템 내부의 파일을 건드리기 때문에 기존에 설정된 권한을 알고 있어서 644나 755같은 권한 설정 방법을 이용합니다.
하지만 권한을 변경하려고 하는 파일이 원래 가지고 있던 권한을 모른다면 u+x와 같은 방법을 사용해야 합니다. 의도치 않게 제 3자에게 권한을 부여하거나, 관련된 사용자에게 권한이 없어질 수 있기 때문입니다.
ls 명령 예
ls에서 -a는 모든 파일 보기(숨겨진 파일 보기) 옵션입니다. -l은 자세한 정보 보기 입니다. 자세한 정보가 필요하지 않더라도 오히려 보기 편해서 -l 옵션은 항상 넣습니다.
[PLEXDRIVE] [2017-10-29 23:09] ERROR : Command not found
터미널에 위와 같은 오류가 나오면 plexdrive가 제대로 설치된 것입니다.
PlexDrive는 rclone과 달리 초기 구성 과정이 필요하지 않습니다. Google Drive만 지원하고 하나의 원격 연결만 지원하지 때문에 PlexDrive로 마운트 명령을 실행할 때 초기 구성 과정을 진행합니다. PlexDrive는 제작자가 미디어에 최적화 되어 있다고 설명한 만큼 별다른 옵션이 필요하지 않습니다.
터미널에서 plexdrive로 Google Drive 마운트를 위한 명령을 실행합니다.
plexdrive mount -o allow_other -v 4 /Home/KollHong/PlexDrive/GoogleDrive
초기 구성 과정이 시작됩니다.
Google Application Client ID를 물어봅니다. rclone과는 달리 자세한 설명이 안내됩니다.
Client ID와 Client Secret을 입력하고 나면 하나의 주소가 나옵니다. 이 링크를 복사하여 웹 브라우저에서 열고, PlexDrive에서 마운트할 Google Drive 계정으로 로그인합니다. 로그인 하면 나타나는 token을 복사하여 PlexDrive에 붙여넣습니다.
그러면 PlexDrive가 Google Drive를 마운트하고 캐싱 작업을 시작합니다.
[PLEXDRIVE] [날짜] INFO : First cache build process started...
문제가 없다면 위와 같은 메시지와 함께 첫번째 캐싱이 시작됩니다. Google Drive에 있는 파일에 따라 기다려야 하는 시간이 달라집니다.
[PLEXDRIVE] [날짜] INFO : First cache build process finished!
