El freno que el sistema no te enseña

En campo he visto memorias SD dañadas por el calor y Raspberry Pi que se pasman cuando el calor aprieta, sobre todo si al calor del lugar le sumas el del procesamiento. En el laboratorio, en cambio, la Pi nunca se había frenado: en las pruebas de la Round 1 la temperatura máxima fue de 65 °C.

Pero esas pruebas duraban entre tres y treinta y un segundos. Así que puse a trabajar a la Pi y al N100 setenta minutos sin parar, registrando todo, para ver qué pasa cuando el modelo no descansa.

La prueba

Los dos equipos con su enfriamiento de siempre: la Raspberry Pi 5 de 8 GB con disipador y ventilador dentro de un gabinete metálico, y el Intel N100 de 8 GB en su mini PC con ventilador. Un cuarto ventilado, sin sol directo. Los dos recién reiniciados.

El modelo, YOLO26n en FP32 con ONNX Runtime, corriendo sin pausa en cuatro fases: dos minutos en reposo, treinta con un proceso que usa los cuatro núcleos, diez de enfriamiento y treinta con cuatro procesos de un núcleo cada uno. Cada inferencia queda registrada, y cada segundo, la temperatura, la frecuencia que reporta el sistema y, en la Pi, dos cosas más que sólo su firmware sabe: el reloj real del procesador y las banderas con las que avisa que se está frenando.

Lo que pasó en la Pi

Entra a la zona de freno en ocho minutos. La Pi 5 empieza a frenar sus núcleos entre los 80 y los 85 °C. Llegó a 80 °C en el minuto 8, la propia Pi marcó su límite como activo en el minuto 10.6, y ahí se quedó hasta el final de la fase, con un máximo de 85.1 °C.

El sistema dice que no pasa nada. La frecuencia que reporta Linux se quedó en 2,400 MHz los treinta minutos. El reloj real, el que reporta el firmware, estuvo por debajo de eso la mitad de la fase: en los últimos cinco minutos promedió 2,283 MHz, y en algunos momentos bajó a 1,500. Es la línea gris contra la ámbar de la gráfica.

Y el modelo se hace más lento, poco. De 7.76 inferencias por segundo al principio a 7.58 al final: 2.3 % menos. La latencia pasó de 128.3 a 131.2 ms. Con este enfriamiento, la Pi sostiene el trabajo; lo paga con unos cuantos puntos de velocidad que ninguna herramienta del sistema muestra.

Con cuatro procesos, menos calor y menos trabajo. En la segunda fase, cuatro procesos de un núcleo llegaron a 80.7 °C, el reloj no bajó, y el equipo hizo 6.7 inferencias por segundo: menos que las 7.6 de un solo proceso con cuatro núcleos. En la Pi, repartir el trabajo así no conviene.

Lo que pasó en el N100

El N100 trabaja mucho más caliente. Con un proceso llegó a 98 °C; con cuatro, a 102 °C, cerca del límite del chip, que anda por los 105. Una advertencia sobre este dato: el N100 empezó la prueba ya caliente, a 85 °C, porque venía de otra medición; el punto de llegada importa más que el de partida.

Ahí sí se ve el freno en la frecuencia: en la fase de cuatro procesos bajó de 2,790 a 2,514 MHz, y la velocidad del equipo, de 18.7 a 18.0 inferencias por segundo, un 3.9 % menos, con la latencia de cada inferencia subiendo 4.3 %. Al revés que en la Pi, en el N100 cuatro procesos sí rinden un poco más que uno: 18.7 contra 17.7.

Lo que dice

Los dos se frenan con trabajo sostenido, aun con ventilador y en un cuarto ventilado. El costo en treinta minutos fue chico —entre 2 y 4 %— y va creciendo, no se queda quieto.

Una prueba de segundos no lo ve. Con las corridas de la Round 1, la Pi estaba a 65 °C y a toda velocidad. Es la misma Pi.

En la Pi, el sistema no lo enseña. Si vigilas el freno con la frecuencia que reporta Linux, no vas a ver nada. Lo que sí lo muestra es la latencia, el reloj real del firmware y sus banderas de freno.

Lo que no dice

Treinta minutos por fase, no días. Un cuarto ventilado, no un gabinete al sol ni una caja cerrada en un poste. Una unidad de cada equipo. En campo, con más calor y sin pausas, todo esto se mueve en la misma dirección, y más.

Y una cosa que no pude explicar: la primera vez que corrí esta prueba, la Pi dejó de responder a los veintisiete minutos de la fase de cuatro procesos, sin calor fuera de lo normal, y no volvió hasta que se reinició al día siguiente. En la ronda limpia, ya con el registro del sistema disponible para saber por qué, no se repitió. Queda anotado, no explicado.

Lo que haría

Medir sostenido antes de prometer una latencia para campo. Horas, en el gabinete donde va a vivir el equipo, hasta que la temperatura deje de subir. Lo que se mide ahí es lo que se puede prometer.

Registrar junto a cada medición la temperatura, el reloj real y las banderas de freno. En la Pi, vcgencmd measure_clock arm y vcgencmd get_throttled. Sin eso, un benchmark no distingue un modelo lento de un equipo caliente.

Vigilar el freno en producción. La Pi guarda si se frenó desde el último arranque. Ese dato en el reporte periódico del equipo cuesta unos bytes y avisa antes de que el cliente note que todo va más lento.

Cuidar el almacenamiento. Una SD de grado industrial o un SSD, y escribir lo menos posible. El calor y las escrituras juntos son lo que acaba con ella.

Los datos de esta prueba —cada inferencia y cada segundo de temperatura, reloj y banderas de los dos equipos— están en crtdrops.mx/datos, bajo licencia CC BY 4.0.

Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años construyendo sistemas que llegan a producción: telemetría, rastreo vehicular, videovigilancia municipal, control de activos por RFID y plataformas transaccionales.