Você tem experiência com o Kernel Liquorix?

Linux Avançado/Terminal
1

Oi pessoal, eu estou elaborando um material sobre o Kernel Liquorix, um Kernel que tem algumas configurações diferentes em tempos de resposta, reduzindo a latência em 50% para algumas atividades. Não se impressionem com o número, se algo reduz de 0,75ms para 0,37ms corre o risco de você nem perceber a diferença.

Esse post vai especialmente para quem já testa, gosta ou usa o Liquorix diariamente, fiz alguns benchmarks daqui dele na versão 5.1, contra o generic 5.0.x no “Rise of the Tomb Raider” e francamente a diferença não foi grande, na média geral deu 2FPS de diferença em favor do Liquorix, sendo que as mínimas em alguns casos ficaram melhores no generic do que no Liquorix. Parece que caiu na margem de erro nesse caso específico.

Isso levanta alguns questionamentos, por isso, gostaria que, especialmente quem utiliza esse Kernel, comentassem se sentiram diferença sobre esses fatores:

  • Você usa ele em hardware high-end ou low-end?
  • Sente diferença em games?
  • Sente diferença em algum tipo de atividade?
  • Porque você confia no Liquorix?
  • low latency padrão ou liquorix?

Especialmente em relação a última, eu não consegui encontrar um contexto mais amplo, alguém explicando ou mesmo uma entrevista com o dev. Me parece um fork do Linux normal, mas compilado com essa modificações, algo feito por um cara só, mas que aparentemente recebe uma força da comunidade, já tem pacotes para Debian, Ubuntu, Arch e Gentoo diretamente no site.

Em fim, o que acham dele? Você tem alguma informação relevante para compartilhar?

Para fins de informação, apesar de ser uma versão mais antiga, tem esse bench da galera da Phoronix:

Dá pra ver que o Liquorix acaba se destacando em tarefas bem específicas, como alguns tipos de compilação, o que talvez não justifique a troca para o usuário médio ou para quem busca aprimoramento em jogos, mas fica o assunto em aberto. Nos testes executados acima, praticamente todo o bench envolvendo aceleração de GPU acabou não influenciando tanto, fazendo ele perder até em vários casos.

Valeu galera, seus comentários poderão aparecer em um vídeo do canal sobre o assunto.

Abraços!

3 curtidas
2

Eu uso o Zen Kernel do Arch, que possui os mesmo patches do Liquorix. Tenho um hardware intermediário (APU da AMD de 2015 - A10 8700P - com 8GB de RAM.)

Se houver apenas uma “coisa”, apenas uma tarefa com a qual eu me importe, rodando no PC, o kernel Zen e o “médio” não possuem diferença alguma. No entanto, o que eu observo é que o Zen é melhor em malabarizar tarefas. No kernel normal, era quase impossível rodar uma tarefa pesada no fundo sem prejudicar as tarefas “normais” na “frente”. Com o Zen, dá pra compilar, renderizar vídeo, atualizar o sistema no fundo e outras coisas pesadas sem prejudicar, por exemplo, web browsing. Claro que milagres não estão sendo feitos e essas tarefas pesadas tão demorando mais - eu observei um acréscimo de 10% no tempo de renderização do KDEnlive, por exemplo. Se você não é um multitarefas ou usuário do AUR, não lhe recomendaria o Zen/Liquorix.

Especificamente sobre games, como eu geralmente fecho tudo e rodo eles sós, não há diferença alguma em relação ao generic. E eu confio porque está lá no repo, hue.

Não tenho experiência com o kernel low-latency e, pelos comentários que leio em comunidades como o Reddit, não faria bem ao meu caso de uso. Ele deixa o kernel ainda mais focado nas tarefas pesadas de fundo, que é oposto do que o Zen faz e me beneficia.

1 curtida
3

Queria saber também a diferença real desse liquorix para o lowlatency, eu uso o lowlatency só porque gosto de brincar com audio uma hora ou outra, e ele ajuda demais pra mexer com o jack, fica bem melhor que o generic.

Mas para jogos é 6 por meia duzia, eu tenho um PC fraco (FX 6300, 8GB, GTX 750 1GB), e em jogos fica tudo a mesma coisa, provavelmente porque só o jogo em questão tá sendo executado no momento, e o limite tá sempre na VRAM., eu to me virando com essa plaquinha aqui, 1GB de VRAM é complicado…

4

Eu concordo com o @Capezotte. Nunca utilizei um Kernel lowlatency, mas sou formado em Ciência da Computação e já vi palestras sobre esse tema, então tenho algum conhecimento no tema. Na minha visão os kernel lowlatency não são feitos necessariamente para tornar uma tarefa mais rápida e sim mais responsiva. Por exemplo, suponha uma indústria química que possui sistemas de controle que não podem falhar e que precisam de respostas imediatas, independente do que esteja acontecendo e quantos programas de verificação estejam sendo executados. Nesse caso, se algo falhar a ação de emergência deve ser executada imediatamente, e inclusive a diferença de ms faz diferença aqui. Usar um Kernel lowlatency é o ideal nessas situações.

Como o Capezotte falou, isso reflete na execução de multitarefas, pois como o esquema de prioridades é diferente a responsividade também acaba sendo diferente, impedindo que alguma aplicação fique travada enquanto outra não termina. Outro bom exemplo é o que o @DanielRios549 disse, de gravação/reprodução de áudio.

Porém, esses Kernels não são adequados em todas as situações, pois comprometem outras coisas como energia, eficiência das tarefas mais longas, … Procurando por mais informações para escrever essa resposta encontrei esse link, que explica melhor esses “poréns”: UbuntuStudio/RealTimeKernel - Community Help Wiki

Eu não creio que haverá muitas diferenças nos testes em jogos, mas seria legal tentar emular um sobrecarregamento do sistema, por exemplo com múltiplos scripts rodando concorrentemente e verificar como os diferentes kernels se saem.

Por exemplo, algo que eu percebi fazendo alguns trabalhos durante o meu curso é que ao imprimir muita coisa no terminal a partir de um programa poderia fazer o programa rodar mais lentamente, pois a impressão de coisas na saída padrão é uma operação cara e não é crítica e por isso tem menos prioridade. Porém, ao ficar mexendo o mouse o texto era impresso mais rapidamente e o programa consequentemente também rodava mais rapidamente, pois a interface tinha prioridade de execução e acabava levando no bolo as requisições do meu programa. É claro que isso acontecia pois os computadores que tínhamos acesso eram bem simples e as vezes até compartilhados entre mais de um usuário, e os programas também ocupavam praticamente 100% das CPUs. Tentar reproduzir isso atualmente em forma de reprodução de vídeo (usando a CPU) ou algo do tipo enquanto roda outras coisas pesadas pode ter resultados interessantes no lowlatency.

2 curtidas
5

Algo que me veio na cabeça agora é que também seria bem interessante fazer os testes dos “poréns”, justamente para mostrar que esses Kernels não são a solução para todos os problemas. Medir o consumo de energia seria legal, por exemplo.

6

Quais tipos de kernel existem?

7

Obrigado pela colaboração, muito legal. :slight_smile:

Você acha que um teste de workload rodando várias VMs ao mesmo tempo com a intenção de sobrecarregar a RAM e o CPU/GPU seria um teste válido nesse caso? Ainda que sejam várias tarefas seriam várias tarefas do mesmo app, ou seria exatamente para esse senário que o Liquorix se encaixaria?

1 curtida
8

Opa! É sempre bom ajudar!

Ser várias tarefas do mesmo app não influencia, mas talvez várias VMs só vão acabar com a RAM e não sobrecarregarão tanto a CPU. Se a RAM lotar e começar a usar o Swap o problema é outro (memória lenta do disco, pois mesmo sendo um SSD não será mais rápido que a RAM).

A GPU também eu acho que não influenciará em nada, apenas pode amenizar o sobrecarregamento da CPU, o que para o teste que você quer fazer não é a intenção. A GPU normalmente recebe poucos comandos provindos da CPU para executar tarefas grandes em paralelo que a CPU demoraria muito para processar. Os Kernels que você quer testar impactam justamente no agendador de tarefas da CPU, e se tem pouca tarefa pra executar (apenas enviar para a GPU) não vai fazer muita diferença.

Para facilitar a percepção da galera, acho que o ideal é tentar sobrecarregar apenas a CPU enquanto faz uma outra tarefa, para reduzir as variáveis. O problema é que se seu computador for muito forte, será difícil chegar nas situações em que o “mouse trava” enquanto faz os testes, mas é esse o ponto. Talvez seja mais fácil testar essas coisas em um PC mais simples.

Umas ideias que tive é testar a responsividade do mouse/teclado em jogos que demandam bastante CPU, latência da webcam/microfone enquanto faz outras coisas (nesse caso também entrariam na jogada os ALSA/Jack/… da vida, mas ainda assim eu acho que pode haver uma melhora), jogar um jogo leve que demanda boa precisão dos controles (cs, super meat boy, flappy bird, …) enquanto executa outras tarefas pesadas, rodar várias tarefas cotidianas ao mesmo tempo (vídeo no YT, OBS, Kdenlive, fazer cálculos em planilha ou no octave, compilar coisas, rodar uma VM, …) e verificar como fica a usabilidade.