Bolas enfriadoras

Hace un tiempo comenté que, para evitar el recalentamiento de mi portátil, lo levanto sobre trabas de la ropa.

Cuando eso no basta, por ejemplo, porque fuerzo al ordenador a trabajar al 100% durante horas, lo que hago es ponerle debajo de la entrada del ventilador unas bolas enfriadoras. Las mismas bolas plásticas rellenas de gel que se guardan en el congelador y que uso para enfriar los refrescos.

Instalar Lenny

Con las copias de seguridad hechas (gracias a mi bienamado dirvish), voy a hacer una instalación desde cero de Debian 5.0 (antes conocida como Lenny). Ya después haré otras cosas feas como pasarme a testing (Squeeze) o incluso a unstable (Sid), con tal de que no se suban a la parra de KDE 4, que no quiero ni ver (al menos por ahora), pero quiero disfrutar de uno o dos días de estabilidad con mi portátil antes de lanzarme.

Servicio al cliente (II) - Refactored

Comenté en mi bitácora usual hace unos minutos cómo me fue con el Servicio de Atención al cliente de Dell. Y quería comentarlo de nuevo aquí, con algunos detalle técnicos más de los que puedo permitirme poner allí.

Viene el caso de que mi portatil se estropeó este fin de semana, y hace un rato llamé al servicio de Atención al cliente de Dell, en particular al servicio técnico.

El síntoma inicial fue que la pantalla estaba en negro. Por completo. Inicialmente pensé que tenía un problema con el salvapantallas o el ahorro de energía (lo que no sería novedad ya que llevo con problemas de ese tipo varios meses y no me he decidido a arreglarlo, sobre todo porque aún no tengo un disco de copias de seguridad), así que cambié a una consola y me empecé a mosquear: seguía en negro.

A ciegas me identifiqué con la consola como superusuario y reinicié el ordenador (no es difícil, basta con ir a una consola que sepas o suponga que on está abierta y poner el nombre de usuario, esperar un poco, poner la contraseña, esperar dos pocos, y escribir poweroff). Ahí empezó mi susto: el reinicio continuaba con la pantalla completamente en negro, tanto para la BIOS como para el GRUB como posteriormente. Curiosamente, la pantalla respondía perfectamente a las órdenes de cambio de brillo, pasando de negro oscuro a negro brillante. Apagué de nuevo el ordenador (lo tuve que hacer a lo bruto porque no me podía identificar en la consola, y no sabía por qué).

Al rato conseguí una pantalla externa y la probé: el modo de vídeo del arranque era inadecuado (80x24), el texto en pantalla aparecía desdibujado y era imposible iniciar el servidor gráfico. La conclusión era evidente: el problema no era de la pantalla, sino de la tarjeta gráfica. Y en un portátil, es parte de la placa base.

Al llamar hoy a Dell les indiqué los síntomas del problema, y me obligaron a hacer la prueba de acceso directo a la pantalla: encender el ordenador con la tecla Fn pulsada, introducir n y comprobar la pantalla. Y efectivamente aparecieron en mi pantalla los colores blanco, rojo, verde y azul, confirmando mi diagnóstico de que no se trataba de la pantalla sino de la tarjeta gráfica.

No consideraba yo necesaria la prueba, pero entiendo que me hicieran comprobarlo dado que muchas veces los usuarios, que no tienen apenas conocimientos sobre la máquina que usan (si se tratara de un coche no aprobarían el examen del carnet de conducir), creen que falla una cosa cuando se trata de otra.

En resumen, mañana tendré un técnico en mi despacho cambiándome la placa base completa por una nueva. Así es como se cuida a los clientes: respuesta adecuada y en un tiempo adecuado.

Trabas

Uno de los culpables del calentamiento global es, sin duda, el cada vez más elevado consumo de energía por parte de los ordenadores. Y no solo por el CO₂ que se emite al generar esa energía, sino por el propio calor que los procesadores desprenden. Basta con entrar a una sala de servidores decentemente refrigerada y acercarse a los armarios de cálculo para comprobarlo.

Pero no solo de servidores vive el hombre, ni solo a ellos les afecta el calor. De hecho, a los ordenadores portátiles les afecta más. Es bastante común poner un portátil sobre una mesa (con lo cual sus patitas lo separan de ésta ligeramente). Y también ponérselo sobre las piernas en el sofá, delante de la tele, y cosas parecidas. Pero el detalle importante de estas actitudes es que los portátiles se refrigeran por debajo, y si bloqueamos esa entrada de aire, o es insuficiente, el portátil se recalentará.

Incluso un portátil colocado sobre una mesa, levantado por sus propias patas de goma, se recalienta si está trabajando en serio. Claro que mucha gente no lo nota porque sus portátiles no hacen cálculo numérico, solamente escribir cartas y leer correos, pero... ¿de verdad quieres ver tu portátil trabajando con el estrangulador al 12%? O peor, ¿quemado?

Si, como yo, pones tu portátil realmente a prueba, no necesitas comprar esos elevadores USB con ventilador tan monos que hay en muchos sitios a la venta... sobre todo porque aparte de costar dinero, el ventilador USB consume más aún la batería del portátil (o eleva la factura de la luz). No. Basta con cuatro trabas de la ropa.

El estrangulador del procesador

Los procesadores modernos (me refiero a la familia de los x86) tienen una característica muy interesante: el estrangulador (throttling) del procesador.

Muchas veces hemos oído hablar de características de los procesadores para portátiles como la de bajar la frecuencia de trabajo cuando se utiliza la batería, para que dure más. Pero el caso es que hay otras características que nos ayudan a hacer lo mismo, y mejor. Se trata de los estados de throttling del procesador, que fuerzan al mismo, independientemente de lo cargado que se encuentre, a <<echarse a dormir>> parte del tiempo. Estos estados se identifican con la letra T. El Intel Centrino Duo T2400 de mi portátil, por ejemplo, tiene 8 de estos estados de estrangulamiento, desde el T0 hasta el T7. Cuando está en el estado T0 el procesador no descansa: siempre está ejecutando algo, aunque sea el <<ciclo idle>>, y por lo mismo además siempre está gastando energía. En el estado T4, por ejemplo, el procesador estará dormido el 50% del tiempo: todas las operaciones que el usuario (o el sistema) trate de hacer, incluso a la máxima frecuencia, tardarán el doble de lo que tardarían en el estado T0.

Hoy en día, con núcleos Linux como el 2.6.26 que tengo funcionando, con las implementaciones modernas de ACPI, el estrangulador no es la vía preferida para cambiar la capacidad (ni el consumo) del procesador. Para eso están los cambios de frecuencia (los estados P del procesador), que son lo que normalmente podemos cambiar con herramientas de usuario como KPowersave. Otro día hablaré más profundamente sobre los estados P, los estados T, los estados S, los estados C, los estados G e incluso los estados D.

Antiguamente, cuando no se podía cambiar la frecuencia de los procesadores, los estados T eran la única manera de hacer que gastaran menos. Como expliqué arriba, esto se consigue poniendo el procesador a dormir por cortos períodos de tiempo, que en mi caso pueden llegar al 88% del tiempo total, dejando sólo el 12% del tiempo para ejecutar realmente instrucciones. Hoy, normalmente no se cambian estos estados salvo en caso de emergencia térmica: si el procesador está sobrecalentado por exceso de trabajo (y una ventilación o disipación deficiente), el sistema puede estrangular el procesador para obligarle a gastar menos energía (y así generar menos calor) incluso bajo las demandas más altas por parte del usuario.

Pero se pueden cambiar a mano para ver sus efectos.

Los núcleos Linux de hoy en día están cambiando sus interfaces ACPI del tradicional /proc al nuevo /sys, pero este cambio todavía no ha finalizado y nos las tenemos que ver con ambos. Para los estados T, en particular, vamos a requerir trastear con los ficheros de /proc/acpi/processor/. En este directorio veremos que hay un directorio por cada núcleo de procesador: /proc/acpi/processor/CPU0/, /proc/acpi/processor/CPU1/, etc. Utilicemos /proc/acpi/processor/CPU0/ como ejemplo. En su interior veremos varios ficheros, de los cuales nos va a interesar, en este caso, /proc/acpi/processor/CPU0/throttling. Este fichero nos indica qué estados de estrangulamiento soporta nuestro procesador (8 en el ejemplo inferior), qué tiempo duerme el procesador en cada uno de ellos y qué estado está en uso actualmente:

$ cat /proc/acpi/processor/CPU0/throttling
state count:             8
active state:            T0
state available: T0 to T7
states:
*T0:                  100%
T1:                  87%
T2:                  75%
T3:                  62%
T4:                  50%
T5:                  37%
T6:                  25%
T7:                  12%

En este ejemplo vemos que el sistema tiene 8 estados de estrangulamiento (state count), numerados de T0 a T7 (state available y la lista states), los tiempos de procesador activo de cada uno, del 100% activo (0% durmiendo) del T0 al 12% activo (88% durmiendo) del T7 (la lista states) y que el estado actual es el T0 (active state y el * en la lista states).

Se puede cambiar el estado a mano, siendo el superusuario, mediante una sencilla orden típica de /proc:

# echo 4 > /proc/acpi/processor/CPU0/throttling

o bien

# echo T4 > /proc/acpi/processor/CPU0/throttling

Si estás tratando de subirlo y no funciona, es que tu máquina está demasiado caliente y el sistema obliga al estrangulador a bajar el consumo para generar menos calor. Recuerda que cada watio gastado es un watio de calor que hay que sacar del sistema. Si sacas menos calor del que generas, el sistema se calienta y puede quemarse.

Un ejemplo: poner mi portátil sobre una esterilla aislante y poner la máquina a calcular hashes para el aMule pone la máquina en T7 independientemente de lo que yo haga. Simplemente levantarla 1cm de la esterilla aislante con unas pinzas de la ropa lleva al sistema a T4 casi inmediatamente y a T0 en unos 30 segundos. Y además en T0 el sistema responde mejor ;)

Información sobre la batería

Recientemente los núcleos de Linux han dejado de proporcionar la información de la batería que antes se encontraba en /proc/acpi/battery/BAT0 y ahora se considera que utilizar /proc para esas cosas está desaconsejado, debiéndose utilizar /sys. Pero por ningún sitio encontré información sobre en qué sitio de /sys se encuentra ahora esa información.

Y positivamente no es en /sys/bus/acpi, /sys/firmware/acpi ni /sys/module/acpi.

Después de mucho buscar (incluso buceando en los parches de varias herramientas para adaptarse al cambio) lo he encontrado: /sys/class/power_supply.