최근 수정 시각 : 2023-08-02 08:00:50

링스

1. Lynx2. 아타리의 휴대용 게임기3. 붕괴: 스타레일의 등장인물4. 웹 브라우저5. 독일의 보병전투차6. Warframe에 등장하는 로봇7. 헝가리의 대물 저격소총8. 인피니티에 등장하는 병종9. 러시아의 산탄총10. 영국의 헬리콥터11. LinX

1. Lynx

스라소니를 뜻하는 영어.

2. 아타리의 휴대용 게임기

파일:상세 내용 아이콘.svg   자세한 내용은 아타리 링스 문서
번 문단을
부분을
참고하십시오.

3. 붕괴: 스타레일의 등장인물

파일:상세 내용 아이콘.svg   자세한 내용은 링스(붕괴: 스타레일) 문서
번 문단을
부분을
참고하십시오.

4. 웹 브라우저

파일:lynx.namu.wiki.png
  • 나무위키를 볼 수 있다.

터미널, DOS에서 사용할 수 있는 텍스트 브라우저이다. 1992년에 출시된 브라우저. 낡은 것 같지만 쿠키, 캐싱, 브라우징 로그 등 지원할 건 다 지원한다.

또 (유니코드 한정으로) 한글도 지원한다. 하지만 어찌 된 일인지 구글 한국 홈페이지에서는 영어, 숫자 및 기호만 나온다.

JavaScript는 애석하게도 지원하지 않기에 JavaScript 지원을 전제로 한 페이지에서는 재미있는 일을 경험할 수 있다. 당연하지만 이미지, CSS, 프레임셋 등도 지원될 리 없다.

검색 엔진은 텍스트밖에 볼 줄 모르기 때문에 검색 엔진이 페이지를 본 것과 비슷한 환경을 체험할 수 있다.

5. 독일의 보병전투차

파일:상세 내용 아이콘.svg   자세한 내용은 링스 보병전투차 문서
번 문단을
부분을
참고하십시오.

6. Warframe에 등장하는 로봇

파일:상세 내용 아이콘.svg   자세한 내용은 링스(Warframe) 문서
번 문단을
부분을
참고하십시오.

7. 헝가리의 대물 저격소총

파일:상세 내용 아이콘.svg   자세한 내용은 게파트 대물 저격총 문서
번 문단을
부분을
참고하십시오.

8. 인피니티에 등장하는 병종

파일:상세 내용 아이콘.svg   자세한 내용은 링스 부대 문서
번 문단을
부분을
참고하십시오.

9. 러시아의 산탄총

파일:상세 내용 아이콘.svg   자세한 내용은 RMB-93 문서
번 문단을
부분을
참고하십시오.

10. 영국의 헬리콥터

파일:상세 내용 아이콘.svg   자세한 내용은 슈퍼 링스 문서
번 문단을
부분을
참고하십시오.

11. LinX

오버클럭 후 시스템의 안정성을 확인하기 위해 사용하는 프로그램 중 하나. 오버클럭 후 윈도우 진입에 성공했다고 해서 실사용이 되지는 않는다. CPU 오버클럭을 실사용이 가능한지 확인하는 프로그램 중, Prime95와 함께 가장 유명한 것이 바로 이 LinX이다. 현재 원 제작자인 Aleksandr Gusev는 손 뗀지 오래이므로 최신 버전은 여기에서 받을 수 있다.[1]

실체는 인텔이 MKL(Math Kernel Library)로 만든, 슈퍼컴퓨터용으로 선형대수 등의 수학연산을 최적화한 LINPACK이다. (여담으로 Prime95는 메르센 소수를 찾기 위한 분산컴퓨팅[2]이 본 목적이다.) LinX는 단지 이것을 오버클럭 테스트 용도로 쓰기 좋게 GUI 프론트엔드를 제공하는 역할밖에 없다. 실제로 LinX를 설치해보면 항상 LinX.exe 외에 하위폴더에 linpack_xeon64.exe 같은 이름의 프로세스가 존재하며 테스트시 CPU를 점유하는 것도 저 녀석이다.[3] 2019년 6월 AMD와 인텔 프로세서 및 한국어/영어를 모두 지원하는 0.9.4 버전으로 업데이트 되었다. 다만 3세대 이후 라이젠 CPU는 호환성 문제를 해결 못해서 AVX 계열의 명령어 셋을 이용하지 않는 문제가 있다. 해당 문제가 해결될 때까진 Prime95에서 AVX, AVX2 모두 활성화된 모드로 확인하는 것이 좋다.

AVX, AVX2 같은 일반 프로그램들에서는 쉽게 지원하지 않는 최신 SIMD 명령어들을 이용하여 CPU를 극한까지 쥐어짠다. 이 상태에서 같은 연산을 여러 차례 돌려서 연산결과가 동일하게 나오는지 확인하는 게 테스트 원리이기 때문에, 오버클럭에 비해 쿨링이 조금만 부실해도 쓰로틀링이 작렬하는 것을 볼 수 있다. 특히 AVX2를 지원하기 시작한 하스웰, 일명 '핫스웰'(...)부터 발열의 지옥을 맛볼 수 있는데, 여길 보면 알겠지만 기본 클럭에서도 쓰로틀링을 맛볼 수 있는 제품도 있다.[4] 때문에 일부러 AVX까지만 지원하는 마지막 버전인 0.6.4를 쓰는 경우도 있다. 당연히 테스트 신뢰성은 떨어지지만, 일반적으로 AVX2를 사용하는 프로그램을 잘 쓰지 않으므로[5] 문제없이 실 사용이 가능할 수도 있다. 판단은 각자 알아서... 다만, 17년 말에는 LinX를 업데이트 하시는 분도 이런 관점에서 구버전 Linpack을 사용한 LinX - Legacy를 내놓았다.[6] 인텔도 이를 인정하는지, 브로드웰-E부터 AVX 사용시 CPU 배수를 낮추는 기능을 제공하고 있다. 브로드웰-E에서는 기본값 Off의 선택적 기능이고 카비레이크부터 기본적으로 활용하는 듯하다. 비슷한 꼼수로 LinX 테스트 시에만 모든 쿨링 팬을 최고속도로 올리고 하는 방법도 있다. 이 역시 실 사용에서 LinX 수준의 발열을 낼 만한 경우가 거의 없다는 것에 착안한 꼼수. 물론 꼼수의 강도에 비례해서 테스트 신뢰성은 떨어지니 알아서 적당히 하자. 심한 경우 케이스 옆판 열고 따로 선풍기 틀어주는 경우도 있다고 하는데, 계속 옆판 열고 할 게 아니라면 링스만 통과하고 정작 실 사용에서 에러날 확률이 꽤 높다.

여튼, CPU 온도가 중요하므로 CPU 온도 모니터링 프로그램을 같이 켜놓고 보는 게 좋다. 다만, 모니터링 프로그램이 점유하는 CPU 사용량도 아래서 설명할 지플값에 영향을 줄 수 있기 때문에 realtemp coretemp 같이 CPU 온도 모니터링에만 특화된 가벼운 프로그램을 쓰는 게 좋으며, 다른 부분(온도 및 잔차)의 정상을 모두 확인 후 최종적으로 지플값만 확인할 땐 저것들마저 끄라고 하는 사람도 있다.

연산결과(한국어판 기준 '잔차')가 다르게 나오면 무조건 실패이고, 이게 다 정상이어도 부동 소수점 실수 연산 속도를 의미하는 GFLOPS(일명 지플값 혹은 지롭값)로 표시되는 연산 성능이 매 회마다 심하게 변동하면 역시 실 사용 시 에러가 튀어나올 확률이 꽤 있어서 실패로 친다. (다만 지플값은 오직 Linpack만이 CPU를 점유하는 상황[7]에서 최소 수 GB 이상의 메모리를 할당한 상황에서만 제대로 확인할 수 있다. 안 그러면 정상적인 노오버 상황에서도 출렁거릴 수 있다.) 최근에는 따로 윈도우의 하드웨어 에러 카운트도 봐야 하는 듯. 주로 HWiNFO란 프로그램을 쓴다. # 다만 모니터링 하는 게 많아서 그런지, 오히려 다른 거 다 정상인데 지플값이 변동하는 결과가 나올 수가 있는데, 시스템 전체 메모리 점유율이 97%가 조금 안 되도록 (링스의) 메모리 할당량을 조금 낮춰주면 해결된다고 한다. (그래도 해결 안 되면 그냥 오버실패다. 보통 전압을 한두 단계 올려줘야 해결된다.) HWiNFO에서 안 볼 부분을 없애고 쓰기도 한다. # (본문 및 VOcean 댓글 참고)

가끔 관련 검색을 하다보면 Prime95가 더 낫다는 얘기도 볼 수 있는데, 구버전[8] 얘기거나 L3 캐시 및 메모리 계통 에러의 얘기[9]이므로 적당히 걸러듣는 게 좋다.

Anandtech CPU 및 오버클럭 포럼의 안정화 테스트 가이드라인에서 어떻게 얼마나 돌려야 되는지에 대한 기준을 제시하고 있고, 평가도 좋으므로 참고해 보자.

LinX를 사용한 오버클럭 안정화는 유독 한국에서만 많이 사용하는 방법이라고 알려져 있다. 해외에서는 CineBench R20, Corona Benchmark, Blender를 연속으로 여러 번 돌려서 에러가 나지 않은 상황에 안정화가 되었다고 판정하거나 ASUS의 스트레스 테스트 프로그램 RealBench를 사용하는 경우가 있다고 한다. 그러나 이는 안정화 기준 자체가 국내에 비해 널널하기 때문이지, 실제로 안정화가 되는 건 아니다. 어디까지나 '오류나면 재부팅하면 되지' 마인드로 쓰니깐 저런 게 가능한 거지 순정에 준하는 신뢰성을 추구하는 국내 커뮤니티 기준에선 시네벤치, Blender 같은 건 아무리 많이 연속으로 돌려도 아무 소용이 없다. 여기에 대고 '그렇게 따지면 안정화 테스트 자체를 안 해도 되는 거 아니냐'고 하는 건 잘못된 흑백논리다. '오류나면 재부팅하면 되지' 마인드라도 그 오류가 너무 자주 나면 짜증나니깐 아주 최소한의 간이 테스트로 저런 걸 돌리는 거다.

RealBench는 국내 기준으로도 안정화를 확인할 수 있는 최소한도 + 이것저것 한 번에 다 테스트할 수 있는 장점 때문에 많이 쓰이는 편인데, LinX 기준으로 말하는 안정화는 RealBench를 아무리 많이 돌려도 절대 확인할 수 없다. 실제 저 기준으로 3세대 라이젠 CPU를 오버할 땐 LinX 대용으로 Prime95를 켜고 돌리지, 저런 널널한 툴을 메인 테스트로 쓰지 않는다. OCCT로 돌려서 보는 방법도 있지만 5.2.0 버전부터 AMD CPU일 때 AVX를 비활성화하는 규칙으로 변경되어서 부적합하다. ( OCCT의 CHANGELOG 항목 참조) OCCT의 CPU 부하 방식도 기본적으로 인텔의 LINPACK을 이용하기 때문.[10]

다만 라이젠 자체 특성상 한계 클럭을 25MHz라도 넘기면 Blender 3회도 못 돌리고 아예 싹 다 오류가 나는 경향이 있기 때문에, Blender 3회 통과할 정도 클럭이면 진짜로 안정화 되어 있거나 그 직전일 가능성이 높긴 하다. # 하지만, 이때도 전압을 애매하게 낮게 주었을 경우에는 조금만 부하 수준을 높이면 오류 작렬하기 때문에 맹신은 금물이다.

2020년 5월에 출시된 인텔 10세대 코어 i 시리즈와 조합되는 Z490 칩셋 기반 메인보드들의 세부 램 타이밍인 tFAW, tRRD_L, tRRD_S 기본 값이 이전 세대보다 너무 풀려져 10세대 코어 i 시리즈 CPU에 부하를 제대로 가할 수 없는 문제가 발생했다. 다행히 해당 세부 램 타이밍을 수동으로 조정하면 예전처럼 부하를 강하게 가할 수 있지만, 메인보드 제품마다 세부 램 타이밍 기본 값이 제각각인데다 세부 램타이밍을 과하게 쪼이면 램 온도를 올리고 CPU 사망을 유발하기 때문에[11] 다루기 빡세다. 세부 램 타이밍을 다룰 줄 모르는 초보자들에게는 더 이상 권장하는 스트레스 테스트용 프로그램이 아니게 되었다.

당장의 치명적인 문제는 아니지만 10코어 20스레드인 i9-10900K, 10900의 경우는 스레드 개수가 i9-9900K, 9900보다 더 많아서 똑같은 세부 램 타이밍 값이라도 메인 메모리 성능 병목 현상까지 심해져서 갈구기가 불리해지는 잠재적인 문제가 있는데 이는 LINPACK이 메인 메모리와 긴밀하게 연계하면서 연산하는 방식 때문. 오버클러커들 사이에서는 i9-9900K에서도 이미 그런 조짐이 있었다고 한다. 그런 구조적인 특성 때문에 tFAW, tRRD_L, tRRD_S의 레이턴시가 획기적으로 개선되지 않는 이상 CPU의 코어 및 스레드 개수가 증가될수록 메모리 성능 병목이 더 심해져 부하가 제대로 가하지 못할 것으로 보이지만 다행히 아직까지는 tFAW, tRRD_L, tRRD_S 값들만 어느 정도 조여줘도 Prime95급 이상의 부하를 가할 수 있는 수준이라 스트레스 테스트로써 완전히 쓸모없지는 않다. 다루기 불편해졌을 뿐.


[1] 사실 비슷하게 IntelBurn이란 프로그램이 먼저 나왔으나, LinX보다 먼저 개발이 끊기고 이어받은 사람도 없어서 LinX에 대체되어 완전히 잊혀졌다. 그리고 19년 초 현재 LinX도 한국어만 업데이트하고 있는 관계로 외국에서는 Linpack Xtreme이란 껍데기를 따로 만들어서 쓰는 모양이다. # [2] 이 녀석의 일종이 헬조선의 악용으로 유명한 그리드 컴퓨팅(...). [3] 이 때문에 AMD CPU 지원이 어려운 편이다. 아예 못 하는 건 아닌데, 지원을 했다가 포기했다가 왔다갔다 한다. 16~17년 초 기준으로 AMD CPU가 불도저 같은 거(정확히는 스팀롤러와 엑스카베이터) 밖에 없어서(...) 지원을 잘 안 하고 있었으나, 라이젠의 선전에 힘입어 17년 5월 30일부터 AMD 에디션이 나오기 시작했다. [4] 다만 일반적인 데스크탑 CPU 사용으로 인정하지 않기 때문에 불량 판정은 없다. 인텔 공식 기준을 따르는 Intel Processor Diagnostic Tool에서 에러가 떠야 인정하는 게 일반적. 당연하지만 링스, 프라임에 비하면 한없이 강도가 낮다. [5] 설령 쓴다 하더라도, 실용 프로그램의 작업들은 AVX2를 쓸 수 있는 작업과 없는 작업들이 섞여 있어서 LinX 수준으로 극악하게 CPU를 쓰는 경우는 극히 드물다. 대표적으로 고해상도 HEVC 인코딩의 경우 최신 인코더들일수록 AVX2를 활용하는 편이라 AMD Ryzen의 상대 성능이 떨어지는 편인데(Ryzen 1,2세대의 AVX2 쓰루풋은 동급 인텔 CPU의 절반 수준이라 LinX의 지플값도 그 정도 수준으로 나온다) 이조차도 최신 LinX에 비하면 널널한 편이다. [6] 단, 구버전들과는 시기가 워낙 차이나는 관계로 레거시라고 해도 0.6.5 AVX2보다 높은 부하를 건다. [7] CPU 점유하는 다른 프로그램 다 끄고 돌리라는 얘기. [8] 원 제작자가 손 뗀 관계로 AVX 및 AVX2 지원이 뒤쳐지던 시절이 있었다. [9] 밑의 가이드라인을 보면 알겠지만, LinX가 강력한 건 순수 CPU 코어 계통의 에러이므로 L3 캐시나 메모리 계통 에러에는 Prime95 및 메모리 테스트 프로그램에 비해 약한 편이다. [10] OCCT는 한때 유명한 툴이었으나 지포스 500 시리즈에서 해당 툴로 돌릴 때만 부하를 낮추는 꼼수 때문에 신뢰성이 떨어지고, 몇 년간 개발이 끊긴 사이에 묻혀서 듣보잡이 되었다. 그러다가 2019년에 들어서 하프라이프 3랑 친구인 줄 알았던 차기 5버전이 마침내 나온 후로 폭풍 버전업 중이라 다시 조금씩 알려지고 있는 상황이다. [11] 당연히 램이 과열되면 에러가 발생한다. 이걸 방지하려면 방열판이나 스팟쿨링이 필요해지는데, 보통 일반적인 램을 끼운다면 이런 부분에 대해서는 크게 신경을 못 쓴다.