¿Por qué elegir un kernel de baja latencia sobre uno genérico o en tiempo real?

93

Después de instalar Ubuntu Studio 12.04, descubrí que usa un kernel de baja latencia. Busqué por qué y cómo volver a cambiar a uno en tiempo real o genérico. Pero parece que esta parte de Linux no se ha cubierto tanto.

P: ¿Por qué elegir un kernel de baja latencia sobre uno genérico o en tiempo real?

PD: Ya he leído las respuestas de esta pregunta y esta publicación.

    
pregunta Starx 28.04.2012 - 05:09

4 respuestas

55
  

Estas son algunas pautas simples proporcionadas para ayudarlo a comprender qué   núcleo, y en qué orden, debe probar para adaptarse a su caso de uso.

     
  • Si no requiere baja latencia para su sistema, utilice el núcleo genérico.
  •   
  • Si necesita un sistema de baja latencia (por ejemplo, para grabar audio), utilice el núcleo libre de errores como primera opción. Esto reduce la latencia   pero no sacrifica las funciones de ahorro de energía. Está disponible solo para   Sistemas de 64 bits (también llamados amd64).
  •   
  • Si el kernel solicitado no proporciona suficiente baja latencia para sus necesidades (o tiene un sistema de 32 bits), entonces debe probar el   -lowlatency kernel.
  •   
  • Si el kernel de latencia no es suficiente, entonces debería probar el kernel -rt
  •   
  • Si el kernel -rt no es lo suficientemente estable para ti, entonces debes probar el kernel -realtime
  •   

enlace

Supongo que depende de lo que hagas con tu distro de estudio. Para algunos usuarios, genérico simplemente lo hará bien, para otros no.

DISCURSO DE LIBERTAD, intente leer este enlace: enlace

    
respondido por el ubuntu fan 28.04.2012 - 05:21
45

Soy el autor del blogpost vinculado por el fan de ubuntu: enlace

Esa publicación de blog no presenta ningún hecho, solo es teoría . Es la forma en que funciona, en realidad: el procesador "se detiene" con mayor frecuencia para ver si hay algunos procesos que requieren atención inmediata. Esto significa que esos procesos se ejecutarán antes que los demás, por lo que no saltará los marcos al codificar ni tendrá un gran retraso entre los clics del mouse y las muertes de los enemigos. No significa que todos los procesos terminarán antes: en realidad, la CPU está perdiendo una mayor parte de su tiempo decidiendo qué proceso se ejecutará a continuación, y haciendo el cambio de contexto. Por lo tanto, el tiempo total de ejecución es más largo, y es por eso que nadie ejecuta un kernel preferente en un servidor web o máquinas de bases de datos. Pero un kernel preferente de 300Hz (o incluso 1000Hz) es el mejor para los servidores de juegos.

Pero hoy en día los procesadores tienen muchos núcleos, por lo que cuando hay pocos procesos que requieren atención, pueden asignarse fácilmente a un núcleo diferente en lugar de esperar que un núcleo lo tome.

(stackexchange me exige referencias / experiencia personal: soy ingeniero electrónico, noobgamer sediento de sangre que mantiene varios servidores de juegos en enlace ).

Así que, como regla general, diría: si su procesador es un poderoso núcleo cuádruple de alta frecuencia y no suele abrir toneladas de páginas web mientras codifica / descodifica / juega (huh) , podría probar el kernel genérico (o i686, o amd64 si existen) y tener el rendimiento más alto posible (es decir, el crunching numérico sin procesar que el procesador puede hacer). Si tiene problemas (en realidad deberían ser menores) o su máquina es un poco menos poderosa que la parte superior del mercado, busque la opción "libre".

Si está en una máquina de gama baja que tiene solo uno o dos núcleos, pruebe con latencia de bajo consumo. También puede probar el tiempo real, pero verá que tiende a bloquear los procesos hasta que los "en tiempo real" hayan terminado su trabajo. Creo que el kernel en tiempo real no es el "vainilla", pero tiene el parche CONFIG_PREEMPT_RT aplicado. Creo que los núcleos en tiempo real son solo para aquellos que tienen que crear una sola aplicación en sistemas integrados, por lo que los usuarios habituales de computadoras de escritorio no deberían tener beneficios reales, ya que generalmente ejecutan un buen número de aplicaciones al mismo tiempo.

Finalmente, las opciones de kernel más relevantes si quiere recompilar su kernel para tener un escritorio de baja latencia son:

PREEMPT=y

y:

CONFIG_1000_HZ=y

Para agregar algo de ahorro de energía, puedes consultar este:

CONFIG_NO_HZ=y
    
respondido por el seven 24.10.2012 - 22:27
6

BTW: preemt-, lowlatency o kernel rt no harán que tu sistema sea más rápido. Son ligeramente más lentos que el kernel genérico.

    
respondido por el gemue2010 28.04.2012 - 05:53
2

Del documento citado anteriormente ( enlace )

  1. un sistema blando en tiempo real dará una latencia promedio reducida pero no un tiempo de respuesta máximo garantizado.
  2. Un sistema duradero en tiempo real cumple con los plazos deseados en todo momento (100 por ciento), incluso en el peor caso de carga del sistema.
  3. Según Yaghmour [4], "en tiempo real se trata de garantías, no a velocidad bruta".

El artículo dice que para el núcleo duro en tiempo real sin respuesta o con límite de tiempo es la propiedad más importante, retrasa la actividad no crítica que lleva a la demora pero a la baja latencia u otro kernel en tiempo real intenta reducir la latencia general que ayuda en la mayoría de los casos. Debido a la latencia reducida, el sistema parece ser rápido. Lea el artículo cuidadosamente.

    
respondido por el Mayank Suman 17.08.2014 - 07:34

Lea otras preguntas en las etiquetas