문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 오버클럭 (문단 편집) == 장단점 및 효율성 논란 == 오버클럭의 단점은 직접적으로는 전기소모량 증가와 부품의 수명단축, 급격한 고장, 역에이징 등이 있다. 따라서 정상적으로 안정적인 고성능을 얻으려면 고가형을 구입하는 것이 좋지만, 클럭의 경우에도 같은 시리즈의 클럭의 차이만으로 제품차이를 준다해도, 저가형의 경우에는 CPU가 저전력, 저발열이기 때문에, 고가형의 경우에는 각 제품간의 가격차가 너무 크기 때문에 오버클럭에 더 전기가 들어간다고 해도 비용의 차이로는 거기서 거기의 차이밖에 못 내게 된다. 성능 자체는 오버클럭을 하는 쪽이 더 낫긴 하다. 그리고 국민오버라고 불리는 오버클럭 정도는 크게 무리를 줄 정도가 아니며, 수명이 짧아진다고 해도 컴퓨터 한대를 천년만년 쓰는게 아니라 적당히 2~3년 지난뒤 좀 더 쓰면 약 5년 정도에 바꿔주기 때문에 큰 상관은 없고 오버클럭이 잘못되었더라도 보통은 부팅이 안될 뿐(이런 경우는 CMOS를 초기화 시키면 해결 가능) 다른 부품과 같이 완전 고장나는 경우는 드문 편이다. 오버클럭에 비용이 많이 들어간다는 주장도 있으나, 이건 어느 정도를 목표로 삼느냐에 따라 다른 문제. 메인보드야 최소 15만 정도를 잡아야 한다고 치더라도[* 물론 바이오스타 전설의 떨이제품 TP67XE나 TZ77XE3, TZ77XE4 같은 예외가 있긴 하다.] 일반적인 국민오버라 불리는 선은 2~3만원짜리 공랭 쿨러로도 충분히 감당이 가능하며 고클럭의 비싼 램은 진짜 램오버를 하고는 싶지만 너무나도 귀찮은 경우가 아닌 이상 필요가 없다. 위 항목에 언급한대로 램오버 자체가 CPU에 비해 엄청 난해하고 귀찮은 작업이다 보니 그냥 제껴버리는 경우가 많기도 하고. 파워 서플라이도 CPU 오버만이 목적이라면 4~5만원선의 적당한 보급형 파워로 버티고도 남는다. 또한 '''전력 관리 기능은 CPU의 퍼포먼스에 영향을 준다'''는 이야기를 곧이 곧대로 믿어 전력 관리 기능을 죄다 꺼버리고 오버한 뒤 전력 소모와 온도 문제로 불평불만하다 순정론으로 돌아서는 경우도 상당히 많은 편. 일반적으로 전력 관리 기능이라는 것이 CPU가 놀고 있을 때 클럭과 전압을 낮추고 유휴중인 부분의 전력을 처단하여 발열과 전력 소모를 낮추는 기능이므로 저걸 다 꺼버리면 CPU가 놀고 있을 때에도 최고 전압과 클럭을 유지하기 때문에 아이들시 발열이나 전력 소모량을 무시할 수 없다. 왜냐하면 CPU의 전력 소모량은 전압의 제곱과 클럭의 곱에 비례하기 때문인데 전력 관리 기능이 작동중일 때의 클럭은 대부분 동작 클럭의 4분의 1 이하, 전압 역시 절반 정도로 내려가기에 부하가 가해지지 않은 상태에서의 소비전력은 매우 적은 편으로 실제 사용 시간의 상당부분은 부하가 가해지지 않는 데다 게임 같이 부하가 가해지는 상황에서도 부하와 부하 사이에 유휴시간이 있기 때문에 평균적으로 소비전력 절약효과를 기대할 수 있다. 다만 전력 관리 기능으로 인해 게임 성능이 떨어질 수는 있다. 클럭과 전압을 한번 낮춘 상태에서 다시 고클럭 상태로 돌아오는 데에는 약간의 지연시간이 있을 뿐만 아니라[* 클럭 자체는 나노초 단위로 바꿀 수 있지만 문제는, 아이들시 저전압 상태에서 클럭만 올리면 전압부족으로 다운된다. 따라서 전압을 먼저 올리고 클럭을 나중에 올려야 되는데 이 전압을 바꾸는 속도는 빨라봐야 수백KHz에 불과하다. 단, FIVR이 통합된 하스웰은 이 속도가 MHz단위로 빠른데, FIVR 기술이 충분히 성숙하지 못했다고 봤는지 바로 다음세대부터 도로 빼버려서 전압 바꾸는 속도는 다시 퇴보했다.][* 이 문제로 욕먹은 스마트폰으로 [[갤럭시 S9/논란 및 문제점#s-1.1.2.1|갤럭시 S9]]이 있다. 자세한 건 해당 서술 참고] [[http://cafe.daum.net/shogun/NTQ8/35|게임이 멀티코어를 잘 못 써서 CPU 점유율이 낮은걸 저클럭 상태로 돌아간다던가]], 이론상으론 성능 손실이 절대 없어야 하는 C1E[* 다른 전력 관리 기능과 달리 정말 CPU내에서 아무 명령어도 실행하지 않고 놀고 있을 때만 클럭을 내린다.]만 켜놔도 성능이 확 떨어지는 해괴한 프로그램이 보고된 사례도 있었고[* 물론 C1E가 처음 생길 당시의 사례이며, 이미 2010년도쯤 되면 C1E가 없는 X86 CPU를 사는게 불가능하다고 해도 될 정도인데 아직도 이정도로 개판으로 짜는 프로그램은 아마 없다고 봐도 되겠다.], CPU는 놀고 있지만 다른 부품은 고성능으로 돌리는 벤치마크(대표적으로 SSD 벤치마크)에서도 전력 관리 기능에 의한 점수차이가 보고되는 사례도 있다. 그렇다고 무식하게 다 꺼버리고 항상 불타는 발열돼지 상태로 쓸게 아니라, 해당 프로그램을 돌릴 때만 잠시 윈도우의 전원 프로파일을 고성능(CPU 클럭을 항상 100% 상태로 유지하는 등 윈도우가 알아서 전력 관리 기능 대부분을 무시해준다)으로 바꿔주는게 좋다. 일일이 수동으로 바꾸는게 귀찮다면, [[RAZER]]의 게임부스터(현재는 CORTEX)등 게임을 한번 등록해 놓으면 알아서 해당 게임 실행시에만 고성능 상태로 바꿔주고, 해당 프로그램을 종료하면 알아서 원상복귀 시켜주는 프로그램을 사용하는 것이 현명하다.[* 단순 전원 프로파일만 바꾸는게 아니라 게임과는 상관없는 상주 프로그램이나 서비스를 잠시 종료하는 등 이것저것 최적화를 해준다.] 윈도우 10도 [[Windows 10/버전/Redstone 5#s-2|RS 5]]의 개선된 게임 모드에서 비슷한 기능을 도입한 것으로 보인다. 오버클럭이 목적이 아니라 전력당 성능 및 발열을 개선하려면 필연적으로 전압 다이어트를 해야 한다. ||전체 소비 전력 = C(전기용량) * V(전압) ^ 2 * F(주파수)|| 이기 때문이다. 옴의 법칙에 따라 소비전력이 전압의 제곱에 비례하기 때문에 성능을 희생하지 않아도 전압을 내려주면 그것만으로도 큰 성능 향상을 얻을 수 있다. 참고로 제조사들은 노오버 상황에서, 여유전압을 어느정도 잡아주는데 다소 안정성에 문제가 생기는 것을 감수하고 5% 내리면 이론상 9.25~19%까지도 전력절감이 가능하며 그만큼 발열도 낮아진다. 물론 이 수치는 이론적인 면이 강해서 실제로는 잔력관리기술의 작동등을 감안하면 감소폭은 이보단 약간 적다. 점수놀이라도 할 게 아닌 이상 일반적인 용도에서 제일 이상적인 오버는 전력 관리 기능과 병행하면서, 즉 CPU에 부하가 걸릴 때만 원하는 클럭으로 작동하게끔 설정해 놓는 것이다. 오버클럭의 진정한 장벽은 '''안정화 작업을 위한 시간과의 싸움'''이다. 보통 안정화를 시킬 때 많이 이용하는 툴로 [[링스#s-8|LinX]]나 [[Prime95]] 등이 있는데, 보통은 [[Prime95]]로 4~5시간은 버텨야 안정화가 된 것으로 본다. 전압이나 클럭 등의 사소한 세팅 변경에도 이 4~5시간의 테스트를 일일이 거쳐줘야 한다고 생각하면 그냥 아득할 뿐. 자는 사이에 돌려놓고 일어나서 확인해 보니 1시간도 통과 못 하고 꺼져 있었다던가 하면 그냥 다 때려치우고 싶은 마음뿐이다. [[하스웰]] 같은 경우에는 0.6.5 버전 LinX(AVX2사용)으로 20번만 갈구면 확실하지만(4시간>평균 30~40분 정도) 미친듯이 발열이 심하다. 사실 사소한 세팅 변경은 최소한의 테스트만하고, 어느정도 세팅이 확실해진 후 최종 테스트로 확실한 안정화를 보는게 현명하다. 그러나 겨울에 안정화를 본 경우, 여름이 가까워오면 그 세팅으론 못 버텨서 안정화 세팅을 처음부터 다시 잡아야하는등, 한번 안정화를 확실하게 봐도 나중에 다시 세팅을 고쳐야 되는 경우들이 있기 때문에, 한번 안정화를 완벽하게 했다고 해서 끝이 아닌 경우가 많다.[* 이런 주변온도 문제가 정히 짜증나면 서버실처럼 PC 사용할 때마다 무식하게 에어컨 돌려서 1년 내내 최대 20도 초반 정도로 실내온도를 유지하면 되긴 한다. 물론 전기요금은 안드로메다로 가겠지만] 현실적인 방법으로 겨울에 테스트 한다면 보일러등을 빵빵하게 틀고 돌리면 다시 테스트 해야하는 일을 줄일수 있다.[* (사실 2020년대가 된 지금 시점에서는 진지하게 여름/겨울 차이는 무시하기도 한다.)] Anandtech 포럼에 효과적인 CPU 및 오버클럭 포럼의 안정화 테스트 [[http://lite.parkoz.com/zboard/view.php?id=over_freeboard&no=17418|가이드라인]]이 올라온 적이 있다. 이런 과정을 안 거치고 그냥 실사용을 통해 안정화를 거치면 되지 않느냐고 하는 이들도 있지만 그러다 중요한 작업 도중 블루스크린이 뜨거나 하면 눈물만 난다.[* 블루스크린이 갑자기 뜰 확률은 클럭이 빨라지면 '''기하급수적'''으로 올라간다. 사실 아무리 잘 만든 노오버 순정 CPU도 정말 재수없으면 블루스크린 뜰 확률이 있긴 하다. 하지만 대부분 짧게는 몇 년, 길게는 몇 십년 정도에 한번 뜨도록 설계되어 무시할 수 있는 수준인 것이다. 하지만 그 확률은 클럭이 빨라지면 기하급수적으로 증가하기 때문에 조금만 올렸더라도 방심하다가 불시에 블루스크린이 떠버릴 수가 있다.] 이 때문에, 일각에서는 전문적인 안정화 툴 사용을 아예 포기하고 간단히 벤치마크만 돌린 다음 사용하는 사례가 보인다. 실제 사용에서는 안정화 툴만큼 부하를 쎄게 주는 사례가 거의 없다시피하기 때문 + 빡센 기준으로 안정화 툴을 다 확인해도 실사용에선 오버클럭 실패 증상이 나와 설정을 후퇴해서 써야 하는 사례는 잊을만하면 하나씩 나오기 때문이라고 전해진다. 물론 벤치마크 프로그램들의 부하는 안정화 툴보다 훨씬 적지만, 어차피 실사용에서 오류나면 재부팅하고 설정 조절할 거라면(또는 사용 용도에 비해 충분히 드문 빈도의 오류라서 참고 쓴다면) 벤치마크 정도의 확인으로도 대부분 충분한 것 아니냐는 반론도 있다. [[링스#s-9]]를 보면 알겠지만, 실제로 외국에서는 그렇게 하는 쪽이 더 대세이다. 안정화 툴에서도 부하를 더 많이 주는 최신 SIMD 명령어들을 제외하고 돌린다는 사례가 많다. 특히 AVX2. 고사양 프로그램에서 이런 명령어를 넣는 사례는 많아지고 있지만, 그렇다고 테스트 툴만한 부하를 주는 경우는 거의 존재하지 않는다. 실용 프로그램의 작업들은 AVX2를 쓸 수 있는 작업과 없는 작업들이 섞여 있어서, LinX 수준으로 극악하게 CPU를 쓰는 경우는 극히 드물다. 대표적으로 고해상도 HEVC 인코딩의 경우 최신 인코더들일수록 AVX2를 활용하는 편이라 AMD Ryzen의 상대 성능이 떨어지는 편인데(Ryzen 1,2세대의 AVX2 쓰루풋은 동급 인텔 CPU의 절반 수준이라 LinX의 지플값도 그 정도 수준으로 나온다) 이조차도 최신 LinX에 비하면 널널한 편이다.[* LinX는 인텔이 MKL(Math Kernel Library)로 만든, 슈퍼컴퓨터용으로 선형대수 등의 수학연산을 최적화한 '''[[http://lite.parkoz.com/zboard/view.php?id=over_freeboard&no=17086|LINPACK]]'''을 사용하고, Prime95는 [[메르센 소수]]를 찾기 위한 분산컴퓨팅이 목적이며, OCCT는 오버클럭 테스트 자체가 목적이다. 대부분 수학 연산이나 스트레스 테스트 자체가 목적이라 (인코딩/렌더링 같은 용도에서는 쓸 수 없을 정도의) 순수 SIMD 최대 활용이 가능한 것]저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기