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

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.}

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

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

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.

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 !