일반 또는 실시간 커널보다 대기 시간이 짧은 커널을 선택하는 이유는 무엇입니까?


105

Ubuntu Studio 12.04를 설치 한 후 지연 시간이 짧은 커널을 사용하는 것으로 나타났습니다. 실시간 또는 일반으로 변경하는 이유와 방법을 검색했습니다. 그러나 Linux의이 부분은 그다지 다루지 않은 것처럼 보입니다.

Q : 일반 또는 실시간 커널보다 지연 시간이 짧은 커널을 선택하는 이유는 무엇입니까?

PS : 나는 이미로부터의 답변을 읽고 질문 게시물을.


3
+1 모든 사람들이 그에 걸렸다면 꽤 좋은 질문이어야하기 때문입니다. 지연 시간이 짧은 일반 커널과 실시간 커널의 차이점을 아직 모릅니다. 경우 -realtime실시간입니다, 다음 무엇 않습니다 -rt약자? 그리고 최대 무엇 -preempt커널? 나는 gemue2010에게 감사 할 것이며, 그는 그것을 잘 설명해 주었지만 여전히 모든 것을 설명하지는 않습니다.
Hitechcomputergeek

답변:


61

다음은 어떤 커널을 이해하는 데 도움이되는 간단한 지침이며 사용 순서에 맞게 테스트해야합니다.

  • 시스템에 낮은 대기 시간이 필요하지 않으면 -generic 커널을 사용하십시오.
  • 지연 시간이 짧은 시스템 (예 : 오디오 녹음)이 필요한 경우 -preempt 커널을 우선 선택하십시오. 이렇게하면 대기 시간이 줄어들지 만 절전 기능은 희생되지 않습니다. 64 비트 시스템 (md64라고도 함)에만 사용할 수 있습니다.
  • -preempt 커널이 요구에 충분한 대기 시간을 제공하지 않거나 32 비트 시스템을 가지고 있다면 -lowlatency 커널을 시도해야합니다.
  • -lowlatency 커널이 충분하지 않으면 -rt 커널을 시도해야합니다
  • -rt 커널이 충분히 안정적이지 않으면 -realtime 커널을 사용해보십시오

우분투 도움말 소스

따라서 스튜디오 배포판으로 무엇을 할 것인지에 달려 있습니다. 빠른 최종 사용자 응답 시간이 필요한 대부분의 사용자에게는 일반 프레임만으로도 충분합니다. 간단한 프레임 드롭만으로도 실시간 커널이 필요한 전문적인 비디오 편집을 수행해야하는 사용자에게는 적합합니다.

보다 이해하기 쉬운 블로그 게시물을 보려면이 링크를 읽으십시오.


1
이미 게시 한 이전 기사를 읽었습니다. 두 번째로, 그 사실은 얼마나 신뢰할 만합니까?
Starx

글쎄, 거기에 언급 된 테스트는 스스로 이야기합니다. 우분투 팀이 처음에 대기 시간을 선택한 경우 그 이유가 있어야합니다. 그래서 당신은 지금 차이점을 알고 싶었습니다. 문제 해결됨 ?
우분투 팬

5
아니요. 문제가 해결되지 않았다고 생각합니다. 당신의 대답이 무엇인가를하면 그것은 나의 호기심을 더 증가시킵니다.
Starx

9
2015 년에도이 중 어느 것이 사실입니까? -preempt, -rt그리고 -realtime커널은 더-이상 존재하지 않는
naught101

51

나는 우분투 팬에 의해 링크 된 블로그 포스트의 저자입니다 : http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

그 블로그 게시물은 사실을 제시하지 않으며 단지 이론 일뿐 입니다. 실제로 작동하는 방식입니다. 프로세서는 즉각적인주의가 필요한 일부 프로세스가 있는지 확인하기 위해 더 자주 "중지"합니다. 즉, 해당 프로세스가 다른 프로세스보다 먼저 실행되므로 인코딩 할 때 프레임을 건너 뛰거나 마우스 클릭과 적사 사이의 지연 시간이 길지 않습니다. 모든 프로세스가 더 빨리 종료된다는 의미는 아닙니다. 실제로 CPU가 다음에 실행될 프로세스를 결정하고 컨텍스트 전환을 수행하는 데 더 많은 시간을 허비하고 있습니다. 따라서 총 실행 시간이 길어 지므로 웹 서버 또는 데이터베이스 시스템에서 선점 가능한 커널을 실행하는 사람이 없습니다. 그러나 선점 가능한 300Hz (또는 1000Hz) 커널이 게임 서버에 가장 적합합니다.

그러나 오늘날 프로세서에는 많은 코어가 있으므로주의가 필요한 프로세스가 거의없는 경우 코어가 처리되기를 기다리지 않고 다른 코어에 쉽게 할당 할 수 있습니다.

(스택 교환은 저에게 참조 / 개인 경험이 필요합니다 : 저는 전자 엔지니어, http://www.gamezoo.it 에서 여러 게임 서버를 관리하는 피에 굶주린 멍청한 게이머입니다 ).

따라서 경험에 따르면 프로세서가 강력한 수의 고주파 쿼드 코어이고 인코딩 / 디코딩 / 게임 (huh) 중에 수많은 웹 페이지를 열지 않으면 일반 (또는 i686 또는 존재하는 경우 amd64) 커널을 시도하고 가능한 가장 높은 처리량 (예 : 프로세서의 원시 수 크 런칭)을 수행하십시오. 문제가 발생하거나 (실제로 경미해야 함) 컴퓨터가 시장의 정상보다 약간 강력하지 않은 경우 -preempt로 이동하십시오.

하나 또는 두 개의 코어 만있는 로우 엔드 시스템 인 경우 -lowlatency를 시도하십시오. -실시간 시도 할 수도 있지만 "실시간"프로세스가 작업을 완료 할 때까지 프로세스를 차단하는 경향이 있습니다. 실시간 커널은 "바닐라"가 아니라고 생각하지만 CONFIG_PREEMPT_RT 패치가 적용되었습니다. 실시간 커널은 임베디드 시스템에서 단일 응용 프로그램을 빌드해야하는 사람들만을위한 것이라고 생각하기 때문에 일반적인 데스크탑 사용자는 보통 상당한 수의 응용 프로그램을 동시에 실행하기 때문에 실질적인 이점이 없습니다.

마지막으로 지연 시간이 짧은 데스크탑을 갖도록 커널을 직접 컴파일하려는 경우 가장 관련성이 높은 커널 옵션은 다음과 같습니다.

PREEMPT=y

과:

CONFIG_1000_HZ=y

절전 기능을 추가하려면 다음을 확인하십시오.

CONFIG_NO_HZ=y

서버 유지 관리에 대해 언급 했으므로 밸브 소스 전용 서버 (CSGO)에 가장 적합한 커널을 찾으려고 노력하고 있습니다. 내가 찾은 대부분의 CS 스레드는 1000Hz 커널이 필요한 goldsrc와 관련이 있습니다. srcds를 사용하면 지연 시간이 짧습니까? 그것이 중요하지 않다면 나는 지금 내가 가지고있는 것이므로 낮은 대기 시간을 고수 할 것입니다 (어쨌든 멀티 스레딩의 이점이 없으므로 128 개의 틱 srcds 서버의 CPU 코어를 분리합니다).
Vincent De Smet

팁을 아는 데 유용하며 선점으로 완전히 바꿀 것입니다. 나는 그렇게 서두르지 않다. 나는 내 커널이 더러운 해적처럼 행동하기를 원한다.
userDepth

4

위에 인용 된 문서에서 ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )

  1. 부드러운 실시간 시스템은 평균 대기 시간을 줄이지 만 최대 응답 시간을 보장하지는 않습니다.
  2. 하드 실시간 시스템은 최악의 시스템로드에서도 항상 원하는 마감 시간 (100 %)을 충족합니다.
  3. Yaghmour [4]에 따르면, "실시간은 원 속도가 아닌 보증을 처리합니다."

이 기사에서는 하드 실시간 커널에 대해 무응답 또는 시간 제한이 가장 중요한 속성이므로 언젠가 지연을 초래하는 중요하지 않은 활동을 지연 시키지만 지연 시간이 짧거나 다른 소프트 실시간 커널의 경우 일반적인 지연 시간을 줄여서 대부분의 경우에 도움을줍니다. 대기 시간이 단축되어 시스템 속도가 빠른 것 같습니다. 기사를주의 깊게 읽으십시오.


사실이지만 어떤 커널 변형이 ​​어떤 실시간 시스템 "경도"와 일치하는지 알아야합니다.
Melebius

0

1600MHz의 듀얼 AMD A6-4400M이 장착 된이 오래된 랩탑을 사용합니다. 사무실 밖에서 주로 이메일을 읽고 캐주얼 웹 사이트를 탐색하는 데 사용합니다. 소프트웨어 업데이트와 연결되어 응답하지 않는 문제가있었습니다. 첫 번째 문자를 보지 않고 12자를 입력하는 것과 같은 것. 프로세스를 강제 종료해야하는지 묻는 위젯이 종종 있습니다.

sudo apt-get install linux-lowlatency재부팅 한 후 원활하고 반응이 좋았습니다. (uname -r 5.0.0-20-lowlatency) 훌륭합니다. 몇 년 전에 바뀌 었어 야 했어요. 세븐의 대답을 강조하겠습니다. 숫자 크 런칭 서버의 최대 값을 짜지 않으려면 -preempt !

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.