Por que escolher um núcleo de baixa latência em vez de genérico ou em tempo real?


105

Depois de instalar o Ubuntu Studio 12.04, descobri que ele usa um kernel de baixa latência. Eu pesquisei por que e como voltar a um genérico ou em tempo real. Mas parece que essa parte do Linux não foi muito abordada.

P: Por que escolher um kernel de baixa latência em vez de um genérico ou em tempo real?

PS: Eu já li as respostas desta pergunta e deste post.


3
+1 porque deve ser uma boa pergunta se todos estão perplexos. AINDA não sei a diferença entre os kernels de baixa latência, genérico e em tempo real. Se -realtimefor em tempo real, então o que -rtsignifica? E o que há com o -preemptkernel? Agradeço ao gemue2010, ele fez um bom trabalho explicando, mas ainda não explica tudo.
Hitechcomputergeek

Respostas:


61

Estas são algumas diretrizes simples fornecidas para ajudá-lo a entender qual kernel e em qual ordem você deve testar para se adequar ao seu caso de uso.

  • Se você não precisar de baixa latência para o seu sistema, use o kernel -generic.
  • Se você precisar de um sistema de baixa latência (por exemplo, para gravar áudio), use o kernel -preempt como primeira opção. Isso reduz a latência, mas não sacrifica os recursos de economia de energia. Está disponível apenas para sistemas de 64 bits (também chamado amd64).
  • Se o kernel -preempt não fornecer latência baixa o suficiente para suas necessidades (ou você tiver um sistema de 32 bits), tente o kernel -lowlatency.
  • Se o kernel -lowlatency não for suficiente, tente o kernel -rt
  • Se o kernel -rt não for suficientemente estável para você, tente o kernel -realtime

Fonte de Ajuda do Ubuntu

Portanto, depende do que você fará com sua distribuição de estúdio. Para a maioria dos usuários que necessitam de um tempo de resposta rápido genérico do usuário final, tudo bem, para outros que precisam fazer edição de vídeo profissional, onde mesmo uma simples queda de quadro é inaceitável, o kernel em tempo real é necessário.

Para uma postagem de blog mais exaustiva e fácil de entender, leia este link


1
Eu já li o artigo anterior que você postou. Quanto ao segundo, quanto esses fatos são confiáveis?
Starx

Bem, os testes mencionados lá falam por si. Se a equipe do Ubuntu escolheu a Latência em primeiro lugar, deve ser uma razão para isso. Então você queria saber as diferenças, agora você sabe. Problema resolvido ?
fã ubuntu

5
Não ... não acho que o problema esteja resolvido. Se sua resposta faz alguma coisa, aumenta mais minha curiosidade.
Starx

9
Isso ainda é verdade em 2015? Os -preempt, -rt, e -realtimegrãos de não mais existe
naught101

51

Eu sou o autor do post do blog vinculado pelo fã do ubuntu: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

Essa publicação no blog não apresenta nenhum fato, é apenas teoria . É assim que funciona: o processador "para" com mais frequência para ver se existem alguns processos que requerem atenção imediata. Isso significa que esses processos serão executados antes dos outros, para que você não pule os quadros ao codificar ou tenha um grande atraso entre os cliques do mouse e as mortes de inimigos. Isso não significa que todos os processos terminarão mais cedo: na verdade, a CPU está perdendo uma parte maior do seu tempo decidindo qual processo será executado a seguir e fazendo a alternância de contexto. Portanto, o tempo total de execução é maior, e é por isso que ninguém executa um kernel preemptivo em servidores da Web ou em máquinas de banco de dados. Mas um kernel preemptivo de 300Hz (ou mesmo 1000Hz) é o melhor para servidores de jogos.

Atualmente, porém, os processadores têm muitos núcleos; portanto, quando há poucos processos que requerem atenção, eles podem ser facilmente alocados em um núcleo diferente, em vez de esperar que um núcleo o aceite.

(stackexchange requer referências / experiência pessoal: sou engenheiro eletrônico, noobgamer sedento de sangue e mantenho vários servidores de jogos em http://www.gamezoo.it ).

Então, como regra geral, eu diria: se o seu processador for um poderoso quad-core de alta frequência e que normalmente não abre muitas páginas da web ao codificar / decodificar / jogar (huh), você pode tente o kernel genérico (ou i686 ou amd64, se existir) e tenha a maior taxa de transferência possível (ou seja, a trituração bruta de número que o processador é capaz de executar). Se você tiver problemas (eles realmente devem ser menores) ou se sua máquina for um pouco menos potente do que a parte superior do mercado, escolha a opção.

Se você estiver em uma máquina low-end que possui apenas um ou dois núcleos, tente a -latitude. Você também pode tentar o -realtime, mas descobrirá que ele tende a bloquear processos até que os "em tempo real" concluam seu trabalho. Eu acredito que o kernel em tempo real não é o "baunilha", mas tem o patch CONFIG_PREEMPT_RT aplicado. Eu acho que os kernels em tempo real são apenas para aqueles que precisam criar um único aplicativo em sistemas embarcados; portanto, os usuários comuns de desktop não devem ter benefícios reais, porque geralmente executam um número razoável de aplicativos ao mesmo tempo.

Finalmente, as opções mais relevantes do kernel, se você deseja recompilar seu kernel para ter uma área de trabalho de baixa latência, são:

PREEMPT=y

e:

CONFIG_1000_HZ=y

Para adicionar alguns recursos, você pode verificar este:

CONFIG_NO_HZ=y

Notei que você mencionou a manutenção de servidores, estou tentando descobrir o melhor kernel para o servidor dedicado à fonte de válvulas (especificamente o CSGO). a maioria dos threads CS que encontro estão relacionados ao goldsrc, que precisava de um kernel de 1000Hz. Com srcds, a baixa latência é ruim? se isso não importa, continuarei com a baixa latência, pois é o que tenho agora (eu isolei os núcleos da CPU para os servidores 128 tick srcds, pois, de qualquer maneira, ele não se beneficia da multi-segmentação).
Vincent De Smet

Útil para saber essas dicas, vou mudar totalmente para antecipar. Não tenho tanta pressa que quero que meu núcleo atue como um pirata imundo.
usar o seguinte comando

4

Do documento citado acima ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )

  1. um sistema flexível em tempo real fornecerá latência média reduzida, mas não um tempo máximo de resposta garantido.
  2. Um sistema rígido em tempo real cumpre os prazos desejados o tempo todo (100%), mesmo com uma carga de sistema do pior caso.
  3. Segundo Yaghmour [4], "o tempo real lida com garantias, não com velocidade bruta".

O artigo diz que para o kernel rígido em tempo real sem resposta ou com limite de tempo é a propriedade mais importante, algumas vezes eles atrasam atividades não críticas que levam ao atraso, mas para baixa latência ou outro kernel em tempo real macio tentam reduzir a latência geral, o que ajuda na maioria dos casos. Devido à latência reduzida, o sistema parece ser rápido. Leia o artigo com atenção.


Isso é verdade, mas precisamos saber qual variante do kernel corresponde a qual “dureza” do sistema em tempo real.
Melebius

0

Eu tenho esse laptop antigo com AMD A6-4400M duplo em 1600MHz, que uso com moderação quando estou fora do escritório, principalmente para ler e-mails e navegar em sites casuais. Havia algo, possivelmente conectado a atualizações de software, o que a deixa sem resposta. Algo como digitar uma dúzia de caracteres sem ver o primeiro. Freqüentemente, o widget pergunta se eu devo forçar o encerramento de um processo.

Após sudo apt-get install linux-lowlatencye reiniciar, tornou-se suave e responsivo. (uname -r 5.0.0-20-lowlatency.) Maravilhoso, eu deveria ter mudado anos atrás. Deixe-me enfatizar a resposta de Seven: a menos que você queira extrair o máximo de um servidor de processamento de números, escolha a opção -prempt !

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.