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

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

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

• Si no necesita baja latencia para su sistema, utilice el kernel genérico.
• Si necesita un sistema de baja latencia (por ejemplo, para grabar audio), utilice el kernel -preempt 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 llamado amd64).
• Si el kernel -preempt no proporciona suficiente latencia baja para sus necesidades (o si tiene un sistema de 32 bits), entonces debería probar el kernel -lowlatency.
• Si el kernel -lowlatency no es suficiente, entonces deberías probar el kernel -rt
• Si el kernel -rt no es lo suficientemente estable para usted, entonces debería probar el kernel en tiempo real

Fuente de ayuda de Ubuntu

Por lo tanto, depende de lo que hagas con tu distribución de estudio. Para la mayoría de los usuarios que necesitan un tiempo de respuesta rápido del usuario final, genérico funcionará bien, para otros que necesitan hacer una edición de video profesional donde incluso una simple caída de fotogramas es inaceptable, se necesita el núcleo en tiempo real.

Para una publicación de blog más exhaustiva y fácil de entender, lea este enlace

Soy el autor del blog publicado por fan de ubuntu: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

Esa publicación de blog no presenta ningún hecho, es solo teoría . Es la forma en que funciona, en realidad: el procesador "se detiene" con más frecuencia para ver si hay algunos procesos que requieren atención inmediata. Eso significa que esos procesos se ejecutarán antes que los demás, por lo que no omitirá fotogramas al codificar ni tendrá grandes tiempos de retraso entre los clics del mouse y las muertes de enemigos. No significa que todos los procesos terminen antes: en realidad, la CPU está perdiendo una mayor parte de su tiempo para decidir qué proceso se ejecutará a continuación y hacer 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 servidores web o máquinas de bases de datos. Pero un kernel preferente de 300Hz (o incluso 1000Hz) es lo 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 a que un núcleo lo tome.

(stackexchange requiere referencias / experiencia personal: soy ingeniero electrónico, noobgamer sediento de sangre que mantiene varios servidores de juegos en http://www.gamezoo.it ).

Por lo tanto, como regla general, diría: si su procesador es un potente núcleo cuádruple de alta frecuencia y gran número y generalmente no abre toneladas de páginas web mientras codifica / decodifica / juega (huh), podría simplemente pruebe el kernel genérico (o i686, o amd64 si existen) y tenga el mayor rendimiento posible (es decir, el procesamiento de números sin procesar que el procesador puede hacer). Si experimenta problemas (realmente deberían ser menores) o su máquina es un poco menos poderosa que la mejor del mercado, vaya a la versión gratuita.

Si está en una máquina de gama baja que solo tiene uno o dos núcleos, intente con la latencia baja. También puede probar el tiempo real, pero encontrará 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 "vanilla", sino que tiene aplicado el parche CONFIG_PREEMPT_RT. Creo que los núcleos en tiempo real son solo para aquellos que tienen que construir una sola aplicación en sistemas embebidos, por lo que los usuarios habituales de escritorio no deberían tener beneficios reales porque generalmente ejecutan una buena cantidad de aplicaciones al mismo tiempo.

Finalmente, las opciones de kernel más relevantes si desea volver a compilar su kernel para tener un escritorio de baja latencia son:

PREEMPT=y

y:

CONFIG_1000_HZ=y

Para agregar algunos ahorros de energía, puede marcar este:

CONFIG_NO_HZ=y

Del documento citado anteriormente ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )

1. Un sistema de tiempo real suave proporcionará una latencia promedio reducida pero no un tiempo de respuesta máximo garantizado.
2. Un sistema duro en tiempo real cumple con los plazos deseados en todo momento (100 por ciento), incluso bajo la carga del sistema en el peor de los casos.
3. Según Yaghmour [4], "los tratos en tiempo real con garantías, no con velocidad bruta".

El artículo dice que para el núcleo en tiempo real duro sin respuesta o con límite de tiempo es la propiedad más importante, por lo que a veces retrasan la actividad no crítica que conduce a un retraso, pero para la baja latencia u otro núcleo blando en tiempo real, intente reducir la latencia general que ayuda en la mayoría de los casos. Debido a la latencia reducida, el sistema parece ser rápido. Lee el artículo detenidamente.

Tengo esta vieja computadora portátil con doble AMD A6-4400M a 1600MHz, que uso con moderación cuando estoy fuera de la oficina, principalmente para leer correos electrónicos y navegar por sitios web casuales. Había algo, posiblemente relacionado con las actualizaciones de software, que hace que no responda. Algo así como escribir una docena de caracteres sin ver el primero. A menudo, el widget pregunta si debo forzar el cierre de un proceso.

Después sudo apt-get install linux-lowlatencyy reiniciar, se volvió suave y receptivo. (uname -r 5.0.0-20-lowlatency.) Maravilloso, debería haber cambiado hace años. Permítanme enfatizar la respuesta de Seven: a menos que desee exprimir al máximo un servidor de cálculo de números, ¡ vaya a -preempt !