Drenaje de batería del portátil durante la noche: el estado de suspensión que miente

La mentira: “suspensión” como término de marketing

La suspensión clásica de los portátiles (la que la gente recuerda con cariño) significaba: la RAM permanece alimentada, la mayor parte del sistema está apagada y la máquina consume una cantidad mínima y predecible de energía. La metías en un bolso, te olvidabas y volvías días después, y seguía bien.

La suspensión moderna a menudo significa: la CPU está “mayormente” dormida, la red puede seguir activa, el sistema puede despertarse brevemente para hacer tareas y algunos dispositivos nunca se apagan completamente porque controladores y firmware no se ponen de acuerdo sobre qué significa “apagado”. Es una mentalidad de centro de datos metida en un chasis alimentado por batería. En un rack de servidores, “despertar para sincronizar el correo” se llama “operaciones normales”. En un portátil a las 2 a.m., se llama “¿por qué mi bolsa está caliente?”

El drenaje de batería durante la noche rara vez es misterioso. Normalmente es uno de estos:

• No obtuviste el estado de suspensión que creías tener (S0 “Modern Standby” / s2idle en lugar de S3 “deep”).
• Obtuviste el estado correcto, pero dispositivos te están despertando (red, USB, Bluetooth, docks Thunderbolt, ratones rencorosos).
• Te mantuviste “dormido”, pero el consumo es demasiado alto por fallos en la gestión de energía de firmware/controladores/dispositivos (NVMe que no entra en estados de baja potencia, Wi‑Fi que se niega a descansar, GPU que permanece medio despierta).
• No te suspendiste en absoluto (suspensión colgada, bloqueada por una app, política de cierre de tapa mal configurada) y la pantalla solo se apagó.

Una vez que dejas de tratar la “suspensión” como una promesa y empiezas a verla como una máquina de estados con registros, esto se puede arreglar.

Hechos interesantes y breve historia (por qué esto empeoró)

Aquí hay algunos puntos concretos de contexto que explican por qué tu portátil de 2012 se comportaba mejor que tu ultrabook de 2023, aunque todo lo demás sea más rápido:

1. ACPI S3 (“suspend-to-RAM”) se remonta a un mundo donde no se esperaba que los portátiles estuvieran siempre conectados. Es simple: RAM alimentada, casi todo lo demás apagado.
2. Microsoft impulsó “Connected Standby” (más tarde llamado “Modern Standby”) para que los PC se comportaran más como teléfonos. Eso es S0 low-power idle, no S3.
3. Muchos portátiles nuevos con Windows se envían sin soporte S3 habilitado en absoluto. Si no puedes usar S3, no puedes “elegirlo” con una configuración; es una decisión de plataforma.
4. S0ix de Intel (estados C del paquete mientras está en S0 idle) es un habilitador técnico clave para Modern Standby. Cuando funciona, es genial. Cuando no, obtienes “suspensión” con actividad de fondo propia de servidores.
5. Las unidades NVMe pueden ser un agresor silencioso. Si el SSD no entra en estados de baja potencia profunda (o el SO no lo permite), la plataforma a menudo no puede alcanzar la residencia de inactividad más profunda.
6. USB-C y los docks Thunderbolt cambiaron el panorama de wake. Un dock es efectivamente un bus de dispositivos, cualquiera de los cuales puede solicitar energía o provocar un wake.
7. El ahorro de energía de Wi‑Fi no es solo una casilla; es una negociación entre SO, controlador, firmware y el comportamiento del punto de acceso. Existen combinaciones malas. Se envían así.
8. Los “wake timers” existen desde hace décadas, pero los mecanismos modernos de actualización los usan agresivamente. Tareas de mantenimiento, telemetría, escaneos de actualizaciones: algunos vendedores los programan como si fuera su portátil, no el tuyo.
9. macOS hace tiempo que usa “dark wake” y mantenimiento programado en segundo plano. Normalmente es bien comportado, pero cuando no lo es, parece un gráfico de batería embrujado.

Una idea parafraseada que los SRE repiten porque es cierta: parafraseado idea de Werner Vogels: “Todo falla, todo el tiempo; diseña y opera asumiendo eso.” La suspensión es simplemente otro sistema distribuido—firmware, controladores, dispositivos, SO, políticas—fallando en pequeñas maneras que se suman hasta una batería agotada.

Guía de diagnóstico rápido (primero/segundo/tercero)

Si estás de guardia por la batería de tu propio portátil, necesitas una triaje que funcione en cinco minutos, no un fin de semana de exploración en foros.

Primero: confirma el estado real de suspensión que obtienes

• Windows: comprueba los estados de suspensión soportados y transiciones de sueño recientes (powercfg).
• Linux: verifica si la suspensión usa s2idle o deep y qué soporta la plataforma (/sys/power/mem_sleep).
• macOS: inspecciona las razones de sueño/activación y las cuentas de “dark wake” (registros de pmset).

Decisión: Si no estás en suspensión profunda (S3/deep) y tu plataforma lo soporta, fuerzalo. Si la plataforma no lo soporta, asume Modern Standby/s2idle y céntrate en las fuentes de wake y la gestión de energía de los dispositivos.

Segundo: identifica fuentes de activación y frecuencia de wake

• ¿Se estaba despertando repetidamente (muchos wakes cortos) o no se dormía de verdad (un largo periodo despierto)?
• ¿La fuente de wake es la red, USB, Bluetooth, tapa, temporizador RTC o “desconocida”?

Decisión: Si los wakes son frecuentes, desactiva las fuentes de wake específicas (Wake-on-LAN, wake por USB, wake por Bluetooth, temporizadores programados). Si los wakes son raros pero el drenaje es alto, céntrate en el consumo en el estado de suspensión (NVMe/Wi‑Fi/GPU/firmware).

Tercero: prueba con variables controladas

• Suspende sin periféricos (sin dock, sin ratón externo, sin almacenamiento USB).
• Desactiva la red temporalmente (modo avión, o desactiva wake on network).
• Prueba la hibernación una noche como control.

Decisión: Si la hibernación lo arregla, tu problema es el estado de suspensión. Si la hibernación sigue drenando, la salud de la batería es sospechosa o el dispositivo no está entrando realmente en hibernación (raro, pero ocurre).

Chiste #1: Modern Standby es como “ayuno opcional.” Tu portátil promete que descansa mientras come silenciosamente vatios en la despensa.

Un modelo mental práctico: a dónde van tus vatios por la noche

El drenaje de batería durante la noche se trata o bien de tiempo (demasiados wakes) o de consumo base (demasiado gasto mientras “duerme”). La solución depende de cuál tengas.

Casos A: el portátil se despierta mucho

Este es el clásico problema de “¿por qué te despertaste?”. Cada wake puede ser corto, pero levanta partes del sistema que son caras: picos de CPU turbo, actividad del radio Wi‑Fi, lecturas/escrituras del SSD o todo un servicio de actualizaciones de fiesta.

Disparadores comunes:

• Wake on LAN / patrones de red
• Wake por USB (ratón, teclado, dock, auriculares)
• Dispositivos Bluetooth reconectándose
• Tareas programadas / wake timers (actualizaciones, agentes de copia de seguridad)
• Ventanas de “mantenimiento” diseñadas por alguien que no viaja con el portátil

Casos B: permanece “dormido” pero consume demasiado

Esto es más sutil y más común en sistemas modernos. La máquina puede no registrar eventos explícitos de wake, pero nunca alcanza la inactividad profunda. Algo impide que el paquete de la CPU y los dispositivos entren en sus estados de menor consumo.

Villanos comunes:

• Unidad NVMe que no entra en baja potencia (APST deshabilitado, firmware con errores)
• Controlador Wi‑Fi manteniendo el sistema en un estado de inactividad superior
• GPU (especialmente dGPU) que no se apaga completamente
• Controladores Thunderbolt activos con dispositivos conectados
• Errores del kernel/controlador que bloquean la suspensión o provocan reanudaciones inmediatas

Por qué “cerrar la tapa” no es una garantía

El cierre de tapa dispara una política. La política provoca una transición. La transición depende de que los controladores cooperen. Si alguna pieza se niega, el SO puede degradarse, atascarse o hacer una semisuspensión. Para el usuario parece “pantalla apagada”. Para la batería parece “todavía trabajando”.

Windows: demuestra qué estado obtuviste y luego busca fuentes de activación

El drenaje de batería nocturno en Windows suele ser un problema de Modern Standby. A veces funciona como fue diseñado. Eso no es un elogio.

Modern Standby (S0 low power idle) versus S3

Si tu sistema solo soporta S0 idle, no puedes forzar S3 con un ajuste de registro mágico que “siempre funcione”. Algunas plataformas literalmente no implementan S3. La jugada correcta es (a) reducir fuentes de wake, (b) restringir la actividad de red en standby, (c) actualizar controladores/BIOS, o (d) elegir hibernar cuando necesites un consumo garantizado bajo.

SleepStudy es tu amigo

Windows tiene un informe incorporado sorprendentemente bueno para el comportamiento de Modern Standby. Mostrará qué componentes estuvieron activos, cuánto tiempo y qué impide la residencia en baja potencia.

No ignores las políticas de “connected standby allowed”

Las imágenes corporativas a menudo vienen con políticas que mantienen la máquina “alcanzable”. Está bien con alimentación AC. Con batería, es un apagón en cámara lenta. Quieres políticas que traten la batería como un presupuesto, no como una sugerencia.

macOS: pmset, darkwakes y las mentiras amistosas

macOS generalmente duerme bien, pero también está muy comprometido a hacer cosas útiles mientras no miras. “Dark wake” es el término educado para “me desperté sin avisarte porque tenía cosas que hacer”. A veces esas cosas son legítimas: copias de seguridad, indexación, sincronización con iCloud. A veces es un controlador o un periférico que causa un bucle de wakes.

Power Nap y wake por red

Power Nap puede despertar el sistema periódicamente. El acceso en red también puede provocar wakes según las configuraciones y el hardware. Si tu Mac se descarga de noche, revisa los wakes repetidos y si se correlacionan con servicios de red o dispositivos USB-C conectados.

Calor en una bolsa es una señal de alarma

Si un MacBook está caliente después de “suspenderse”, eso sugiere que o bien se despertó repetidamente o no entró realmente en un estado de baja potencia. No aceptes “es normal”. Calor significa que la energía fue a algún lado, y no a tu productividad.

Linux: s2idle vs deep, controladores y la trampa de suspensión

Linux te da poder. Linux también te da cuerda. El comportamiento de suspensión varía según el kernel, la configuración de la distro, el firmware y los controladores de dispositivos. Puedes tener un portátil que se suspenda perfectamente en el kernel 6.1 y drene como un calefactor en 6.6, porque un único controlador cambió sus valores predeterminados de gestión de energía.

s2idle (S0) vs deep (S3)

En muchos portátiles, Linux por defecto usará s2idle (una inactividad coordinada por software en S0). Puede estar bien. O puede ser una fuga de batería si los dispositivos no se comportan.

deep corresponde a S3 cuando está soportado. Suele ser más eficiente en energía y menos “charlatán”, pero puede tener problemas de compatibilidad con algunos dispositivos (problemas de reconexión de Wi‑Fi, dispositivos USB que no reanudan, etc.).

Systemd, journald y registros de suspensión

Linux te da el postmortem que siempre quisiste. Si la suspensión falla, los registros a menudo mostrarán qué unidad o controlador lo bloqueó. No adivines; lee el journal.

NVMe y ASPM son ofensores comunes

NVMe APST y PCIe ASPM importan. Si la plataforma no puede bajar los enlaces PCIe a estados de baja potencia, tu consumo base será mayor. Linux puede mostrarse conservador dependiendo de las peculiaridades del firmware del sistema. A veces necesitas habilitar una política; otras veces necesitas dejar de pelear con el BIOS y simplemente actualizarlo.

Hardware y firmware: NVMe, Wi‑Fi, USB y ajustes del BIOS

A los ingenieros les encanta culpar al software porque podemos cambiar el software. El drenaje de batería en suspensión a menudo está mediado por hardware/firmware. Eso no significa que estés atrapado; significa que la solución puede ser “actualizar el BIOS” y no “alternar mil ajustes del SO”.

Configuraciones de BIOS/UEFI que importan

• Selección de estado de suspensión: algunos firmwares exponen conmutadores S3 vs Modern Standby / S0ix.
• Wake on LAN: desactívalo con batería a menos que tengas una razón real.
• Carga USB en suspensión: conveniente, pero cuesta energía. Desactívalo si persigues el drenaje.
• Seguridad Thunderbolt / soporte prearranque: puede afectar el comportamiento de energía con docks.

Los periféricos son culpables hasta que se demuestre lo contrario

Dock + monitor externo + receptor USB + adaptador Ethernet es un sistema distribuido. Y como todos los sistemas distribuidos, falla de maneras creativas a las 3 a.m. Si tu drenaje ocurre “solo cuando está en el dock”, créelo. Aíslalo.

Chiste #2: Un dongle USB puede despertar tu portátil más fiable que tu alarma, y ni siquiera se disculpa.

Tres microhistorias corporativas desde las trincheras

Incidente #1: la suposición equivocada (“La suspensión es suspensión”)

Un gran equipo de TI interno desplegó un nuevo modelo de portátil a un grupo de ingenieros que viajaban con frecuencia. El modelo antiguo tenía una suspensión S3 sólida. La gente cerraba la tapa, tomaba un vuelo y la abría en el hotel con aproximadamente el mismo porcentaje de batería.

El nuevo modelo se envió solo con Modern Standby. La suposición—nunca documentada, nunca probada—era que “el comportamiento de suspensión es el mismo entre portátiles”. No lo era. La primera señal real fue una ola de quejas: “Mi portátil muere en mi bolsa”, “Está caliente”, “Llega al 0% cuando aterrizo”. La segunda señal fue más cara: algunas baterías empezaron a hincharse antes de lo esperado porque pasaban demasiado tiempo calientes en un espacio confinado.

Inicialmente lo trataron como error de usuario. Luego extrajeron informes SleepStudy de un puñado de máquinas. La historia fue consistente: actividad de red repetida durante el standby, temporizadores periódicos y algunos controladores impidiendo la residencia de baja potencia. Nada dramático—solo muerte por mil cortes de papel.

La solución no fue un ajuste mágico único. Ajustaron políticas de energía para restringir la conectividad de red en batería, deshabilitaron capacidades de wake específicas para ciertos controladores NIC y empujaron actualizaciones de BIOS. También cambiaron las directrices de viaje: si vas a poner el portátil en una bolsa por horas, usa hibernación. Fue aburrido. Funcionó.

Incidente #2: la optimización que salió mal (alcanzabilidad siempre activa)

Un grupo de seguridad quería que los dispositivos siguieran siendo alcanzables para comprobaciones de cumplimiento, renovación de certificados e informes de salud del endpoint. Objetivos razonables. Habilitaron temporizadores de wake agresivos y permitieron conectividad de red durante el standby con batería en toda la flota.

“Optimizó” el cumplimiento. También optimizó el drenaje de batería. Los usuarios empezaron a llegar a reuniones con máquinas muertas y una desconfianza refleja hacia el indicador de energía del portátil. Esa desconfianza importa: una vez que la gente deja de creer la telemetría, inventan sus propios rituales—apagar constantemente, desactivar actualizaciones o rechazar configuraciones gestionadas por políticas.

El problema no era la intención de seguridad; era la falta de un presupuesto. El consumo en standby es un presupuesto. Si lo gastas en alcanzabilidad, no puedes también gastarlo en “tener batería por la mañana”.

El compromiso eventual: permitir conectividad de red durante el standby solo con alimentación AC, y con batería solo dentro de una ventana corta después de cerrar la tapa. También hicieron que los temporizadores de wake fueran opt-in para dispositivos asignados a roles específicos. El cumplimiento siguió bien. La confianza en la batería volvió. Todo el mundo dejó de tratar la suspensión como una apuesta.

Incidente #3: la práctica aburrida pero correcta que salvó el día (baseline + control de cambios)

Un equipo de plataforma que soportaba portátiles Linux hizo una cosa que parecía poco glamorosa: mantuvieron una prueba base de suspend/resume y consumo en suspensión en su checklist previo al lanzamiento. Mismo hardware, mismo kernel, misma carga de trabajo, mismos periféricos. Cada vez que actualizaban kernels o BIOS, ejecutaban la misma prueba nocturna.

En un ciclo, notaron que el consumo en standby se había duplicado en un subconjunto de máquinas después de una actualización del kernel. Ningún usuario se había quejado todavía. Tenían datos primero. El journal mostraba suspensiones limpias, pero la máquina se quedaba en s2idle y no alcanzaba estados de baja potencia en los dispositivos, con el subsistema NVMe activo con frecuencia.

Bisectaron el cambio hasta un ajuste de comportamiento de gestión de energía en la configuración de un controlador de almacenamiento que interactuaba con el firmware de un SSD particular. La “solución” a corto plazo fue fijar un parámetro del kernel para los estados de NVMe y trabajar con el proveedor en actualizaciones de firmware. También cambiaron el modo de suspensión predeterminado a deep donde era soportado.

No fue heroico. Fue control de cambios más medición. Así es como “salvas el día” en operaciones reales: detectas regresiones antes de que afecten a tus usuarios, y no te enteras del drenaje de batería por un ejecutivo en un salón del aeropuerto.

Errores comunes: síntoma → causa raíz → solución

Síntoma: El portátil pierde 20–50% durante la noche, y está caliente por la mañana.

Causa raíz: Modern Standby / s2idle con wakes frecuentes o consumo base alto; a menudo relacionado con red o dock.

Solución: Desactivar wake por red/USB, restringir red en standby con batería, actualizar BIOS/controladores, probar suspensión sin periféricos, usar hibernación para viajes.

Síntoma: El drenaje ocurre solo cuando está conectado a un dock o hub USB-C.

Causa raíz: Dispositivos del dock generando eventos de wake; controlador Thunderbolt activo; wake USB habilitado.

Solución: Deshabilitar wake por USB para dispositivos específicos, actualizar firmware del dock, evitar funciones de “USB siempre alimentado”, probar distintos puertos/cables.

Síntoma: La batería se descarga incluso cuando está “apagado”, o el drenaje es mucho peor de lo esperado.

Causa raíz: No está realmente apagado (Fast Startup/hiberboot en Windows), o el dispositivo soporta “carga USB con apagado”.

Solución: Desactivar Fast Startup; en BIOS desactivar la alimentación USB en S5; verificar con registros e informes de energía.

Síntoma: El portátil se despierta inmediatamente después de dormir.

Causa raíz: Dispositivo con capacidad de wake (USB/Bluetooth/NIC) provocando reanudación, o un temporizador de wake.

Solución: Inspeccionar la última fuente de wake; deshabilitar capacidades de wake; limpiar temporizadores de wake; actualizar controladores.

Síntoma: El portátil Linux “suspende” pero los ventiladores siguen girando o las luces del teclado permanecen encendidas.

Causa raíz: Colgado en suspend o degradación; dispositivo/controlador bloqueando; atascado en s2idle con dispositivos activos.

Solución: Revisar el journal alrededor de la suspensión; cambiar a deep; poner en blacklist/deshabilitar módulos problemáticos; actualizar kernel/firmware.

Síntoma: macOS pierde 10–20% durante la noche sin wake obvio.

Causa raíz: Darkwakes repetidos por red/copia de seguridad/indexación, o wakes provocados por periféricos.

Solución: Inspeccionar registros de pmset; ajustar Power Nap/wake por red; desenchufar periféricos sospechosos; restablecer NVRAM/SMC según corresponda (dependiente de la plataforma).

Tareas prácticas con comandos (y cómo decidir)

A continuación hay tareas concretas que puedes ejecutar. Cada una incluye: un comando, salida realista, qué significa y qué decisión tomar. Úsalas como un playbook de incidentes: recopila evidencia, cambia una variable, vuelve a probar.

Tarea 1 (Windows): Comprobar qué estados de suspensión están soportados

cr0x@server:~$ powercfg /a
The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate
    Fast Startup

The following sleep states are not available on this system:
    Standby (S1)
    Standby (S2)
    Standby (S3)
        The system firmware does not support this standby state.
    Hybrid Sleep
        Standby (S3) is not available.

Qué significa: S3 no es una opción. Estás en Modern Standby (S0 low power idle). La “suspensión” no es la clásica.

Decisión: Deja de intentar forzar S3 con trucos. Céntrate en fuentes de wake, políticas de connected standby y gestión de energía de dispositivos. Usa hibernación cuando necesites un drenaje predecible.

Tarea 2 (Windows): Generar un informe SleepStudy (análisis de Modern Standby)

cr0x@server:~$ powercfg /sleepstudy /duration 3
Sleep study report saved to file path C:\Windows\system32\sleepstudy-report.html.

Qué significa: Ahora tienes un informe que detalla sesiones de standby, componentes activos y drenaje.

Decisión: Abre el informe y busca: mayores culpables, “tiempo activo” durante el standby y cualquier componente que impida el estado de baja potencia. Si “Network” o “Audio” o un controlador específico domina, apúntalo.

Tarea 3 (Windows): Encontrar qué despertó la máquina por última vez

cr0x@server:~$ powercfg /lastwake
Wake History Count - 1
Wake History [0]
  Wake Source Count - 1
  Wake Source [0]
    Type: Device
    Instance Path: PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03\3&11583659&0&FE
    Friendly Name: Intel(R) Ethernet Connection (7) I219-V
    Description: Intel(R) Ethernet Connection (7) I219-V
    Manufacturer: Intel

Qué significa: La NIC despertó el portátil.

Decisión: Desactiva wake en la NIC (o desmarca “Allow this device to wake the computer” en el Administrador de dispositivos) especialmente con batería, y desactiva Wake-on-LAN en BIOS si no lo necesitas.

Tarea 4 (Windows): Listar dispositivos permitidos para despertar el equipo

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse
Intel(R) Ethernet Connection (7) I219-V
Intel(R) Wireless-AC 9560 160MHz

Qué significa: Varios dispositivos pueden despertar el sistema.

Decisión: Comienza desactivando wake para todo lo no esencial (ratón, receptor USB, Wi‑Fi, Ethernet). Mantén el wake por teclado si lo deseas. Vuelve a probar por la noche.

Tarea 5 (Windows): Deshabilitar temporizadores de wake (palanca a nivel de política)

cr0x@server:~$ powercfg /waketimers
There are no active wake timers in the system.

Qué significa: No hay temporizadores de wake activos en el sistema en este momento, pero se pueden crear futuros temporizadores por políticas o tareas.

Decisión: Si el drenaje persiste, no te quedes aquí. Revisa Tareas Programadas y la configuración de “Allow wake timers” en tu plan de energía. En entornos gestionados, revisa Group Policy.

Tarea 6 (Windows): Informe de batería para validar el drenaje real en el tiempo

cr0x@server:~$ powercfg /batteryreport /duration 7
Battery life report saved to file path C:\Windows\system32\battery-report.html.

Qué significa: Una serie temporal de uso y drenaje en standby, además de estimaciones de capacidad.

Decisión: Si la capacidad está significativamente degradada, puede que persigas una realidad de hardware. Si la capacidad está bien pero el drenaje en standby es alto, es un problema de suspensión/wake, no de “batería vieja”.

Tarea 7 (macOS): Mostrar razones recientes de sueño/activación

cr0x@server:~$ pmset -g log | grep -e "Wake reason" -e "Entering Sleep" | tail -n 12
2026-02-04 22:31:10 -0500 Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active
2026-02-04 23:12:44 -0500 Wake reason: EC.LidOpen (User)
2026-02-05 01:07:03 -0500 Entering Sleep state due to 'Idle Sleep':TCPKeepAlive=active
2026-02-05 01:18:39 -0500 Wake reason: RTC (Alarm)
2026-02-05 01:22:10 -0500 Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active
2026-02-05 03:34:02 -0500 Wake reason: XDCI (USB)

Qué significa: Estás viendo wakes por alarmas RTC (tareas programadas) y USB.

Decisión: Si el wake por USB se correlaciona con el drenaje nocturno, desenchufa periféricos/docks durante la noche y vuelve a probar. Si los wakes por RTC se correlacionan, revisa Power Nap / comportamiento de mantenimiento programado y agentes instalados.

Tarea 8 (macOS): Inspeccionar la configuración actual de gestión de energía

cr0x@server:~$ pmset -g
System-wide power settings:
Currently in use:
 standby              1
 Sleep On Power Button 1
 hibernatemode        3
 powernap             1
 womp                 1
 tcpkeepalive         1
 ttyskeepawake        1
 disksleep            10
 sleep                15

Qué significa: Power Nap (powernap) y Wake on Magic Packet (womp) están habilitados; TCP keepalive está activo.

Decisión: Si quieres máxima conservación de batería nocturna, desactiva Power Nap y las funciones de wake en red (al menos para casos con batería). Vuelve a probar.

Tarea 9 (Linux): Comprobar si el sistema usa s2idle o deep

cr0x@server:~$ cat /sys/power/mem_sleep
s2idle [deep]

Qué significa: La suspensión profunda está disponible y actualmente seleccionada (los corchetes indican el seleccionado).

Decisión: Si el drenaje sigue alto, probablemente tengas eventos de wake o un dispositivo que no se apaga correctamente incluso en deep. Pasa a fuentes de wake y registros.

Tarea 10 (Linux): Forzar suspensión deep (cuando esté soportado) para una prueba

cr0x@server:~$ echo deep | sudo tee /sys/power/mem_sleep
deep

Qué significa: Has cambiado el objetivo de suspensión a deep para esta sesión de arranque (la persistencia depende de la configuración de la distro).

Decisión: Haz una prueba nocturna. Si el drenaje baja drásticamente, mantén deep por defecto y resuelve los problemas de reanudación de dispositivos por separado.

Tarea 11 (Linux): Revisar registros de suspend/resume alrededor del último sueño

cr0x@server:~$ journalctl -b -1 | grep -E "suspend|Suspend|resume|Resume" | tail -n 20
Feb 04 22:40:11 laptop systemd[1]: Starting System Suspend...
Feb 04 22:40:11 laptop kernel: PM: suspend entry (deep)
Feb 04 22:40:12 laptop kernel: ACPI: EC: interrupt blocked
Feb 04 22:40:13 laptop kernel: PM: suspend exit
Feb 04 22:40:13 laptop systemd[1]: Finished System Suspend.
Feb 04 22:40:13 laptop kernel: usb 1-4: reset high-speed USB device number 7 using xhci_hcd
Feb 04 22:40:14 laptop kernel: iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
Feb 04 22:40:14 laptop kernel: PM: Some devices failed to suspend, or did not enter low power state

Qué significa: El kernel te está diciendo que los dispositivos no se suspendieron correctamente. El controlador Wi‑Fi es sospechoso.

Decisión: Actualiza kernel/firmware para Wi‑Fi, prueba con Wi‑Fi desactivado antes de suspender y examina las fuentes de wake. Si desactivar Wi‑Fi arregla el drenaje, tienes un desajuste entre controlador/firmware/ahorro de energía.

Tarea 12 (Linux): Identificar dispositivos permitidos para despertar el sistema

cr0x@server:~$ grep -r . /proc/acpi/wakeup | sed -n '1,12p'
Device  S-state   Status   Sysfs node
XHC0      S3    *enabled   pci:0000:00:14.0
RP05      S3    *enabled   pci:0000:00:1c.4
GLAN      S3    *disabled  pci:0000:00:1f.6
HDEF      S3    *disabled  pci:0000:00:1f.3

Qué significa: El controlador USB (XHC0) y un puerto raíz PCIe (RP05, a menudo Wi‑Fi/WWAN/NVMe detrás) pueden despertar el sistema.

Decisión: Deshabilita temporalmente el wake para XHC0 para probar si dispositivos USB causan reanudación. Luego vuelve a probar con periféricos desenchufados.

Tarea 13 (Linux): Deshabilitar un dispositivo de wake para pruebas (temporal)

cr0x@server:~$ echo XHC0 | sudo tee /proc/acpi/wakeup
XHC0

Qué significa: Esto alterna la capacidad de wake. Vuelve a ejecutar cat /proc/acpi/wakeup para verificar que cambió a disabled.

Decisión: Si deshabilitar XHC0 arregla el drenaje nocturno, o bien tienes un dispositivo USB/dock ruidoso o un problema con el controlador/controlador del controlador. Entonces decides si mantenerlo deshabilitado, cambiar periféricos o actualizar firmware.

Tarea 14 (Linux): Comprobar qué despertó el sistema por última vez (systemd)

cr0x@server:~$ journalctl -b | grep -E "Wakeup|wakeup|ACPI: Waking up" | tail -n 10
Feb 05 03:34:01 laptop kernel: ACPI: Waking up from system sleep state S3
Feb 05 03:34:01 laptop kernel: xhci_hcd 0000:00:14.0: xHC error in resume, USBSTS 0x401, Reinit
Feb 05 03:34:01 laptop kernel: PM: resume devices took 1.842 seconds

Qué significa: La ruta de reanudación implica el comportamiento del controlador USB.

Decisión: Céntrate en fuentes de wake USB y firmware del controlador; prueba sin dock; considera actualizar el BIOS.

Tarea 15 (Comprobación transversal): Verificar salud/capacidad de la batería (ejemplo Linux)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | sed -n '1,18p'
  native-path:          BAT0
  vendor:               SMP
  model:                5B10W139
  serial:               0123
  power supply:         yes
  updated:              Wed 05 Feb 2026 08:01:22 AM
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              28.4 Wh
    energy-full:         45.2 Wh
    energy-full-design:  57.0 Wh
    capacity:            79.3%

Qué significa: La capacidad de la batería es ~79% del diseño. No es terrible, pero tienes menos margen para el drenaje.

Decisión: Si el drenaje es límite, la capacidad degradada hará que se sienta catastrófico. Aún arreglas el drenaje en suspensión, pero también planificas un reemplazo de batería si dependes de periodos largos sin cargador.

Tarea 16 (Windows): Detectar si “apagar” es en realidad hibernación (Fast Startup)

cr0x@server:~$ powercfg /hibernate
Hibernation has not been enabled.

Qué significa: La hibernación está deshabilitada; Fast Startup también puede verse afectado.

Decisión: Si quieres un “apagado” con drenaje mínimo garantizado, habilita la hibernación y elige hibernar explícitamente para viajes. Si sospechas de “drenaje al apagar”, audita la configuración de Fast Startup y el comportamiento de alimentación USB en BIOS.

Listas de verificación / plan paso a paso

Lista A: Prueba de aislamiento de una noche (la victoria más rápida)

1. Carga al porcentaje conocido (p. ej., 80%). Anótalo.
2. Desconecta todos los periféricos: dock, dispositivos USB, tarjetas SD, pantallas externas.
3. Desactiva Bluetooth para la prueba si puedes.
4. En Windows, pon la red en modo avión o desactiva el “network connected standby” si tus políticas lo permiten.
5. Pon la máquina en suspensión. No solo cierres la tapa si no confías—usa la acción de suspensión del SO.
6. Déjala 8–10 horas.
7. Revisa el porcentaje de batería y la temperatura.

Interpretación: Si el drenaje es mínimo ahora, tus periféricos o dispositivos con capacidad de wake son la causa raíz. Si el drenaje sigue alto, es el comportamiento de suspensión de la plataforma, firmware o un controlador que mantiene el consumo base elevado.

Lista B: Decidir entre S3/deep vs Modern Standby/s2idle

1. Comprueba estados soportados (Windows: powercfg /a; Linux: /sys/power/mem_sleep).
2. Si existe S3/deep: cambia a deep y prueba una noche.
3. Si no existe: deja de llorar por S3. Endurece Modern Standby eliminando fuentes de wake y actividad de red en segundo plano.

Lista C: Bloqueo de fuentes de wake (detener la “guardia nocturna”)

1. Lista dispositivos con wake armado (Windows: powercfg /devicequery wake_armed).
2. Desactiva wake para NICs salvo que sea requerido.
3. Desactiva wake para ratones y receptores USB (generan ruido).
4. Desactiva temporizadores de wake con batería (o restríngelos).
5. Vuelve a probar por la noche.

Lista D: Firmware y controladores (la solución poco sexy que funciona)

1. Actualiza BIOS/UEFI a la versión estable más reciente.
2. Actualiza controladores de Wi‑Fi y chipset (o en Linux, actualiza kernel + paquete de firmware).
3. Actualiza firmware del dock si usas uno.
4. Vuelve a ejecutar tu prueba base nocturna.

Lista E: Usar hibernación estratégicamente

1. Habilita hibernación.
2. Usa hibernación cuando el portátil vaya a estar en una bolsa por horas.
3. Usa suspensión cuando necesites reanudar rápido y el portátil esté en un escritorio.

Interpretación: Hibernación es el modo “la energía cuesta dinero”. Suspensión es el modo “el tiempo cuesta dinero”. Elige según en qué estás gastando.

Preguntas frecuentes

1) ¿Por qué mi portátil se descarga más en suspensión ahora que portátiles antiguos?

Porque “suspensión” a menudo significa S0 low power idle (Modern Standby / s2idle), que permite más actividad en segundo plano y depende mucho de la coordinación perfecta entre controladores y firmware.

2) ¿Modern Standby es inherentemente malo?

No. Cuando la plataforma alcanza estados de inactividad profundos y los eventos de wake están controlados, puede ser eficiente. El problema es que un solo dispositivo con mal comportamiento puede mantener todo el sistema en un estado de mayor consumo.

3) Mi portátil está caliente en mi mochila. ¿Qué debo hacer inmediatamente?

Deja de usar suspensión para transporte en bolsa. Usa hibernación o apaga, y desactiva wake on LAN/USB. El calor es prueba de trabajo, y el trabajo en una bolsa acelera el envejecimiento de las baterías.

4) ¿Desactivar Bluetooth solucionará el drenaje nocturno?

A veces. Los dispositivos Bluetooth pueden provocar wakes o mantener radios activos. Es una buena prueba de aislamiento. Si ayuda, puedes mantener Bluetooth activado pero desactivar capacidades de wake o cambiar el comportamiento de los periféricos.

5) ¿Por qué empeora al conectar a un dock USB-C?

Los docks añaden adaptadores de red, hubs USB, dispositivos de audio y a veces almacenamiento—todas fuentes potenciales de wake. También mantienen controladores Thunderbolt/USB4 activos. Actualiza el firmware del dock y desactiva wake en dispositivos no esenciales.

6) ¿Debería desactivar la suspensión y siempre hibernar?

Si tu prioridad es drenaje garantizado bajo, sí. El intercambio es un reanudar más lento y más escrituras en SSD (generalmente aceptable, pero existe). Mucha gente usa suspensión en escritorio e hibernación para viajes. Ese es el compromiso sensato.

7) En Linux, ¿cuál es la diferencia entre s2idle y deep?

s2idle es un estado de inactividad coordinado por software en S0; depende más del buen comportamiento de los controladores. deep corresponde a S3 suspend-to-RAM cuando está soportado, típicamente menor consumo pero a veces menos compatible.

8) ¿Puede un SSD realmente afectar el drenaje en suspensión?

Sí. Si la unidad NVMe no entra en estados de baja potencia, puede impedir una inactividad de plataforma más profunda. Verás un consumo base mayor sin eventos de wake obvios.

9) ¿Cómo sé si son wakes versus consumo base alto?

Busca registros/informes que muestren muchos eventos de wake (Windows powercfg, macOS pmset logs, Linux journalctl). Si los eventos de wake son raros pero el drenaje sigue alto, sospecha consumo base (estados de dispositivos, firmware).

10) Si actualizo BIOS y controladores y sigue drenando, ¿qué sigue?

Ejecuta la prueba de aislamiento (sin periféricos, radios apagados) y compara suspensión vs hibernación. Si la hibernación está bien y la suspensión no, confirmaste un problema de estado de suspensión. En ese punto, elige hibernación como predeterminada para la noche y sigue cazando el dispositivo/controlador ofensivo en paralelo.

Conclusión: siguientes pasos que realmente detienen la hemorragia

Deja de discutir con la palabra “suspensión”. Trátala como un modo operativo que necesita verificación, registros y un presupuesto. Tu objetivo es un drenaje predecible, no pureza filosófica.

1. Confirma tu estado de suspensión (Windows powercfg /a, Linux /sys/power/mem_sleep, macOS registros de pmset).
2. Realiza una prueba nocturna controlada con todos los periféricos quitados y radios reducidos. Establece una línea base.
3. Elimina fuentes de wake (NIC, USB, Bluetooth, temporizadores) una categoría a la vez, volviendo a probar tras cada cambio.
4. Actualiza BIOS y controladores/firmware críticos antes de intentar soluciones ingeniosas. Lo ingenioso es frágil; los errores de firmware son reales.
5. Adopta la hibernación para viajes y noches si tu plataforma no puede ofrecer suspensión de bajo consumo consistentemente. Esto no es una derrota; es madurez operativa.

Cuando tu portátil se despierta por la noche, debería ser porque tú se lo pediste. Cualquier otra cosa es un incidente. Trátalo como tal.