Límite térmico para un mini PC con Trixie

 Si sois unos "tiquismiquis" como yo, y no soportáis el susurro del ventilador del mini PC cuando más inspirados estáis, aquí os brindo una solución con Debian 13 KDE o "Trixie".

A mi mini PC, con un Intel N5100, le retiré el ventilador, y le puse un disipador de calor en el hueco que dejó tan osado despropósito; pero no basta, es preciso limitar la frecuencia máxima de trabajo del mini PC para que no supere los 80ºC en el peor de los casos.

¿Cómo se puede hacer con "Trixie"?

Con un servicio personalizado de systemd para que cuando iniciemos el sistema la frecuencia máxima quede configurada al valor que deseamos.

 Debemos de instalar previamente el paquete linux-cpupower, y si tenemos instalado Synaptic lo podemos instalar amigablemente:

Luego, creamos en /etc/systemd/system/ el archivo de servicio set-cpufreq.service .

Luego, le añadimos el siguiente contenido para que se establezca la frecuencia máxima en 2.20 GHz al inicio:

[Unit]
Description=Set CPU Frequency Limit to 2.20GHz
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set --max 2.20GHz
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

GUARDAR

 ExecStart: Especifica el comando que ejecutará systemd para fijar la frecuencia máxima.

RemainAfterExit=true: Hace que el servicio siga activo después de ejecutar el comando.

 
 Usando un Terminal, recargamos systemd para que reconozca el nuevo servicio:

sudo systemctl daemon-reload

Luego, habilitamos y arrancamos el nuevo servicio:

sudo systemctl enable set-cpufreq.service
sudo systemctl start set-cpufreq.service

Verificamos la frecuencia máxima con el siguiente comando:

cpupower frequency-info

 Política actual: la frecuencia debe estar entre 800 MHz y 2,20 GHz. El controlador de ahorro de energía puede decidir qué velocidad utilizar dentro de este rango.

Atinar mq-deadline para un mini PC con SSD

 Reducir la latencia y evitar el colapso del sistema cuando se ejecutan las operaciones de lectura y escritura hacia el SSD es el cometido de mq-deadline (Multi-Queue deadline. Multi colas con tiempo máximo). El planificador por defecto de las operaciones de lectura y escritura hacia el SSD en los kernel modernos es mq-deadline, que usa blk-mq (Multi-Queue Block Layer), la moderna arquitectura del kernel que aprovecha las CPUs multinúcleo y dispositivos rápidos como SSD y NVMe.

mq-deadline se basa en tres principios simples:

• Separación de lecturas y escrituras. Las lecturas tienen prioridad, ya que bloquean procesos y afectan directamente a la fluidez del sistema.
• Deadlines por petición. Cada operación tiene un tiempo máximo de espera. Si se alcanza ese límite, la petición se ejecuta inmediatamente, aunque no sea la más eficiente de agrupar.
• Reordenamiento moderado. Agrupa peticiones cercanas cuando es posible, pero sin la complejidad de schedulers (planificadores) antiguos pensados para discos mecánicos.

El resultado es un comportamiento predecible, estable y de baja latencia, ideal para hardware moderno. 

 ¿Por qué mq-deadline es ideal para mini PC?

En mini PC con SSD o NVMe:

• El tiempo de acceso es muy bajo
• La prioridad es la latencia estable
• El consumo de CPU debe ser mínimo

mq-deadline cumple perfectamente estos objetivos:

• Excelente rendimiento en escritorio
• Buena respuesta bajo carga
• Comportamiento robusto en multitarea
• Muy bajo overhead (recursos redundantes para ejecutar una misma cosa)

Por eso es el scheduler por defecto en la mayoría de distribuciones.

 En un Terminal comprobamos si está activo mq-deadline por defecto ejecutando:

 cat /sys/block/sda/queue/scheduler

 

Si devuelve  none [mq-deadline] es que está activo. Si el SSD no está en sda, en el comando anterior ponerle el correspondiente.

Ahora, afinamos esos parámetros que idealizarán la ejecución de mq-deadline en nuestro mini PC:

Ejecutamos en un Terminal con permisos administrativos (root) los siguientes comandos:

echo 0 | tee /sys/block/sda/queue/rotational
echo 256 | tee /sys/block/sda/queue/nr_requests 

(Si usamos sudo, sería asi:

 echo 0 | sudo tee /sys/block/sda/queue/rotational
echo 256 | sudo tee /sys/block/sda/queue/nr_requests )

Reiniciamos el mini PC.
 

Aquí podemos ver el cambio realizado:

Comprobamos con el siguiente comando que está cargado:

ls /sys/block/sda/queue/iosched/

Si aparecen los siguientes archivos después de ejecutar el comando, todo OK.

fifo_batch, read_expire, write_expire, writes_starved

 Con el siguiente comando podemos ver cómo trabaja y cambian los valores de las variables cada vez que lo ejecutamos:

cat /sys/block/sda/stat

En una red social que uso, cuando navegaba --debido a la lentitud de la red WIFI-- tenía un lag que me ponía nervioso, y aunque también me enfurecía por lo que dicen en los comentarios de estas peculiares redes, lo cierto es que en esto y en otros menesteres se nota mejoría evidente.

El Mini con N5100, sin ventilar y ruido alguno, mola con estas pequeñas cosas. 

 

¿CUBIC o BBR+FQ? En mi caso, sin duda, BBR+FQ

 TCP Cubic es uno de los algoritmos de control de congestión de red, y suele ser el predeterminado en Linux, Unix y Windows. Funciona mejor en redes simples, sin WIFI, sin muchos flujos y saturaciones. Suele generar ping largos, lag y microcortes, porque empieza bien, apura locamente hasta que satura los buffers y empieza a perder paquetes, entendiendo así que debe reducir su velocidad, y repite el ciclo. 

A una red WIFI como la mía le va algo más  "inteligente", algo que, de antemano, mida el ancho de banda real, el RTT (Round Trip Delay o tiempo de ida y vuelta en redes sin perder paquetes), y ajuste el flujo de datos a una velocidad de crucero sin perder paquete alguno. Este protocolo es BBR (Botteneck Bandwidth and RTT) + FQ (Fair Queueing)  se ajusta mejor al perfil de las nuevas redes, y el otro, el TCP Cubic está más experimentado, pero nació en otro tiempo.

En todo tráfico tiene que haber un policía, ese es FQ (Fair Queuing), y depende del Kernel, diviendo el flujo en varias colas, reparte justamente la conexión, evita que aparezca el chupón de datos, como la pelota en el fútbol, y reduce el bufferbloat (colas demasiado largas, llenas de ingentes cantidades de datos). Buen poli.  

Hoy, con la IA, cualquiera puede ampliar este tema e investigar sobre ello lo que quiera, pero la experiencia propia todavía se requiere cuando realmente queremos saber hasta qué punto merece la pena cambiar. 

Todo esto es muy interesante, pero la verdad se vive, y no se enseña (cita de Hermann Hesse), por eso me propuse compararlos en la práctica en un miniPC como el mío. 

En un miniPC usado como ordenador personal creamos en /etc/sysctl.d/ el archivo 99-bbr.conf

Yo usé Thunar lanzado desde un terminal con permisos administrativos (root), y luego de forma gráfica cree el archivo en la carpeta correspondiente:

 

A ese archivo le añadimos el siguiente contenido abriendo el archivo, por ejemplo, con Mousepad:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr 

 

Guardar y reiniciar.

 Podemos comprobar si está activado en nuestro sistema usando el siguiente comando en un terminal:

sysctl net.ipv4.tcp_congestion_control 

 

Tendrá que devolvernos bbr 

Usando este otro comando, podemos verificar si el policía se persona en la red:

 tc qdisc show

 

Debe de mostrar algo así:

qdisc fq 0: dev enp1s0 root refcnt 2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028b initial_quantum 15140b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 10s horizon_drop

No colgaría esta entrada  si no tuviera la convicción de que  mereció la pena. En una red precaria como la mía mi miniPC parece agradecerlo, mostrando una agilidad en el "flow" de la WIFI que antes no percibía.

 Ya me contarán. Gracias.