BIOS vs controlador vs Windows: Quién controla su hardware (y cómo probarlo)

Un modelo mental operativo: quién posee qué, cuándo

Piense en el control del hardware como una carrera de relevos con tres corredores y un número sorprendente de bastones perdidos:

• BIOS/UEFI (firmware de plataforma): enciende el sistema, enumera los dispositivos, aplica políticas de plataforma (entrenamiento de memoria, ajustes de enlace PCIe, tablas ACPI) y luego mayormente se hace a un lado.
• Firmware del dispositivo (dentro del SSD/NIC/HBA/GPU): implementa el comportamiento del propio dispositivo: gestión de colas, recuperación de errores, limitación térmica, cachés, negociación de enlace con sus peculiaridades y, ocasionalmente, sentido del humor.
• Controladores: traducen las solicitudes del SO en operaciones del dispositivo; implementan gestión de energía, manejo de interrupciones, configuración de DMA, integración con la planificación de E/S, offloads y ajustes específicos del dispositivo. En los controladores se gana o se pierde el rendimiento a menudo.
• Windows (núcleo + subsistemas de almacenamiento/red): decide la política: planificación, gestión de memoria, comportamiento de la pila de E/S, planes de energía, postura de seguridad y qué significa “saludable”.

Entonces, ¿quién “controla” el hardware? La capa que posee la decisión en ese momento:

• Al arrancar: BIOS/UEFI lleva el volante. Establece el escenario. También decide qué puede creer Windows sobre el hardware mediante ACPI y la enumeración de dispositivos.
• Tras el arranque: Windows y los controladores mayormente conducen. El firmware sigue actuando como los reflejos del dispositivo: limitación térmica, recolección de basura en segundo plano, reinicios de enlace, temporizadores internos.
• Bajo estrés/fallo: el firmware suele convertirse en el verdadero jefe. Si un controlador inicia recuperación de errores o reinicios, el SO solo puede reaccionar.

Cuando depura, no está preguntando “¿quién es culpable?”. Está preguntando:

1. ¿Qué capa está tomando la decisión que corresponde con mi síntoma?
2. ¿Qué evidencia puedo recopilar en 5 minutos para probarlo?
3. ¿Qué cambio es reversible y seguro?

Una cita para mantener la honestidad. Es una idea parafraseada de John Allspaw (operaciones/confiabilidad): idea parafraseada — “No arregla la confiabilidad quien culpa; se arregla aprendiendo cómo el sistema realmente se comporta”.

Broma #1: Si piensa que su servidor “decidió” ejecutar en PCIe x1, felicidades: ha conocido la aventura menos graciosa del mundo.

Contexto histórico y datos interesantes (lo que duele después)

Estos no son datos para la noche de trivialidad. Son hechos del tipo “¿por qué funciona así?”. Los que explican clases enteras de fallos.

1. BIOS no fue diseñado para el hardware actual. El BIOS clásico data de la era temprana de PC; UEFI emergió para manejar arranque moderno, discos más grandes y servicios previos al SO más completos.
2. ACPI es el contrato. Windows depende en gran medida de las tablas ACPI proporcionadas por el firmware para entender estados de energía, topología de dispositivos y características de la plataforma. Un ACPI defectuoso puede parecer un “bug de Windows” durante años.
3. Las Option ROM solían llevar el espectáculo. Los controladores de almacenamiento y red enviaban históricamente extensiones BIOS (Option ROM) que manejaban la inicialización en tiempo de arranque. Los controladores UEFI reemplazaron gran parte de eso, pero comportamientos heredados todavía persiguen las rutas de arranque.
4. NVMe es “simple” por diseño. NVMe redujo capas comparado con SATA/AHCI, pero también hizo más visible la interacción driver/firmware: colas, interrupciones y estados de energía importan inmediatamente.
5. La moderación de interrupciones es vieja, pero aún mal entendida. Las NIC han estado coalesciendo interrupciones durante décadas. Es excelente para el ancho de banda, terrible para cargas sensibles a la latencia, y a menudo se ajusta en los controladores—algunas veces “con buena intención”.
6. Storport reemplazó modelos de almacenamiento anteriores en Windows por rendimiento. Los miniport de alto rendimiento modernos se apoyan en Storport; por eso los controladores HBA/RAID/NVMe se comportan diferente que el almacenamiento “simple”.
7. La gestión de energía en Windows se volvió más agresiva con el tiempo. Los estados C de CPU, PCIe ASPM, políticas de inactividad de dispositivos y modern standby cambiaron las suposiciones por defecto. Genial para portátiles; ocasionalmente picante para servidores.
8. Secure Boot y la firma de controladores cambiaron las reglas del juego. Ya no se puede cargar casualmente controladores de kernel dudosos. Eso es bueno—hasta que intenta probar un hotfix de un proveedor a las 2 a.m.

Límites de control: BIOS/UEFI vs firmware vs controladores vs Windows

Qué controla realmente BIOS/UEFI

BIOS/UEFI controla la plataforma. No “ejecuta” sus dispositivos en estado estable, pero decide las condiciones iniciales:

• Topología PCIe y entrenamiento de enlace (ancho de carril, velocidad negociada, ajustes de bifurcación).
• Entrenamiento y temporizaciones de memoria (y si sus DIMM funcionan a la velocidad anunciada o en “modo seguro”).
• Características de CPU y conmutadores de virtualización (VT-x/VT-d, habilitación SR-IOV en firmware, comportamiento IOMMU expuesto al SO).
• Políticas de energía y térmicas (límites estilo PL1/PL2, curvas de ventilador, “modo silencioso” que hace los servidores silenciosamente lentos).
• Orden de arranque, Secure Boot, TPM, arranque medido.
• Tablas ACPI que Windows lee como escritura sagrada.

BIOS/UEFI también entrega hooks de microcódigo y bits de gestión de plataforma. Pero si está depurando una caída de rendimiento al mediodía un miércoles, BIOS no está en un bucle moviendo sus paquetes.

Qué controla el firmware del dispositivo (y no pedirá permiso)

El firmware dentro del dispositivo es donde vive el “comportamiento del hardware” realmente:

• Recuperación de errores y reintentos: tiempos de espera, abortos, reinicios de enlace, remapeo de bloques malos.
• Limitación térmica: los SSD y GPUs lo hacen; algunas NIC también; el SO lo conoce después del hecho.
• Planificación interna: capas de traducción de NAND, comportamiento de envío/completado NVMe, políticas de caché de controladoras RAID.
• Trabajo en segundo plano: recolección de basura, nivelado de desgaste, lecturas de patrulla, scrubs.

Los bugs de firmware son especiales porque producen síntomas que parecen de controladores, y las soluciones parecen rituales: “Actualizar firmware, reiniciar, y el fantasma se va”. A veces eso es exactamente correcto.

Qué controlan los controladores (su causa raíz más común)

Los controladores se sientan en el límite donde la intención se convierte en realidad:

• Estrategia de manejo de interrupciones: basada en línea vs MSI/MSI-X, afinidad de CPU, moderación/coalescencia.
• Mapeo de DMA: cómo se fijan y mapean los buffers, lo que interactúa con configuraciones IOMMU.
• Gestión de energía: inactividad de dispositivos, estados de enlace, suspensión selectiva.
• Offloads: RSS/RSC/LSO en NIC; profundidad de cola y comportamiento de caché de escritura en almacenamiento.
• Superficie de errores: un bug en el controlador puede bloquear el sistema o “solo” limitar el rendimiento al 30% sin errores.

Los controladores también deciden qué telemetría recibe. Si un controlador oculta detalles, Windows no puede diagnosticar lo que no puede ver.

Qué controla Windows (política y orquestación)

Windows es el planificador, el árbitro y ocasionalmente quien mueve las porterías:

• Planificación de CPU y colocación de hilos.
• Gestión de memoria, incluyendo comportamiento del caché de página que puede hacer que los “benchmarks” de almacenamiento mientan.
• Política de pila de E/S: colas de almacenamiento, comportamiento del sistema de archivos, caching, barreras de escritura.
• Seguridad: HVCI/Memory Integrity, Credential Guard, VBS—estos pueden cambiar las características de rendimiento.
• Planes de energía y políticas de energía de dispositivos.

Windows también aloja los registros de eventos. Si no los lee, está depurando con los ojos vendados.

Guía de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Este es el “tengo 15 minutos antes de que la llamada de incidentes empeore” playbook. El objetivo no es la verdad perfecta. El objetivo es encontrar la capa del cuello de botella con alta confianza y mínima interrupción.

Primero: confirme que el síntoma es real y local

• ¿Es una máquina o muchas? Una sola máquina apunta a “hardware, controlador o configuración local”. Muchas máquinas apuntan a “actualización de Windows, política, cambio de carga o dependencia compartida”.
• ¿Es una clase de dispositivo? ¿Solo almacenamiento? ¿Solo red? ¿Solo GPU? No generalice. Clasifique.
• ¿Puede reproducirlo con una prueba simple? Una sola prueba de lectura de disco, una prueba tipo iperf para una NIC (Windows tiene herramientas), una carga de CPU simple.

Segundo: mapee el cuello de botella a un subsistema

• Almacenamiento: alta latencia de disco, longitudes de cola, reinicios o timeouts de controladora.
• Red: pérdidas, retransmisiones, alta CPU en interrupciones/DPCs o negociación de enlace baja.
• CPU/energía: frecuencia atrapada baja, rarezas de C-state, límites térmicos.
• PCIe: ancho/velocidad de enlace degradado, errores AER, dispositivos que se desconectan.

Tercero: decida qué capa inspeccionar primero

1. Política/configuración a nivel Windows (rápido de comprobar, reversible): plan de energía, características VBS, política de caché de escritura, versiones de controladores.
2. Comportamiento del controlador (medio): interrupciones, offloads, profundidad de cola, reinicios storport, eventos miniport.
3. Firmware/BIOS/UEFI (más lento, más arriesgado): bifurcación PCIe, conmutadores SR-IOV, ASPM, actualizaciones BIOS, firmware de dispositivo.

Regla: si no puede explicar cómo una configuración de BIOS afecta su síntoma, no la toque durante un incidente. Eso no es disciplina; es supervivencia.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente uso. Cada una incluye: comando, qué significa la salida y qué decisión tomar.

Task 1: Identify BIOS/UEFI version and firmware date

cr0x@server:~$ wmic bios get smbiosbiosversion, releasedate
ReleaseDate                SMBIOSBIOSVersion
20231108000000.000000+000  2.1.7

Meaning: You’re looking at platform firmware version and release date. Old firmware doesn’t automatically mean “bad,” but it often means “known quirks.”

Decision: If you see known issues in your environment (PCIe link downgrades, NVMe resets), schedule a controlled BIOS update. Not during the outage.

Task 2: Confirm Windows build and patch level

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Hotfix(s)"
OS Name:                   Microsoft Windows Server 2022 Standard
OS Version:                10.0.20348 N/A Build 20348
Hotfix(s):                 5 Hotfix(s) Installed.

Meaning: Build number matters; kernel/storage behavior changes with cumulative updates.

Decision: If the regression aligns with patch rollout, split the fleet by update ring and compare performance before blaming “hardware.”

Task 3: See what drivers are actually loaded (not what you think is installed)

cr0x@server:~$ driverquery /v /fo table | findstr /I "stor nvme iastor mlx e1d"
stornvme.sys     ...   Microsoft Corporation   ...
storport.sys     ...   Microsoft Corporation   ...
mlx5.sys         ...   Mellanox Technologies   ...
e1d68x64.sys     ...   Intel Corporation       ...

Meaning: The loaded driver is the truth. Device Manager screenshots are vibes.

Decision: If you expected a vendor NVMe driver but see stornvme.sys, your tuning assumptions are wrong. Adjust accordingly.

Task 4: Inspect storage controller errors in the System event log

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129 or EventID=153 or EventID=157)]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-StorPort
  Event ID: 129
  ...
  Description: Reset to device, \Device\RaidPort0, was issued.

Meaning: Event ID 129 is Storport timeout/reset. That’s not “the app is slow.” That’s the storage stack screaming.

Decision: If 129/153/157 show up around latency spikes, stop tuning Windows caching and start investigating driver/firmware and physical layer (cables/backplane/PCIe).

Task 5: Check disk latency and queueing with Performance Counters

cr0x@server:~$ typeperf "\PhysicalDisk(*)\Avg. Disk sec/Read" "\PhysicalDisk(*)\Avg. Disk sec/Write" "\PhysicalDisk(*)\Current Disk Queue Length" -sc 3
"(PDH-CSV 4.0)","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Read","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Write","\\server\PhysicalDisk(0 C:)\Current Disk Queue Length"
"10.000000","0.003412","0.089532","7.000000"
"10.000000","0.002981","0.102114","9.000000"
"10.000000","0.003105","0.095220","8.000000"

Meaning: Reads are fine, writes are ~100ms, queue length is non-trivial. That’s usually device/firmware throttling, cache disabled, write barrier pressure, or a controller in pain.

Decision: If write latency is high but CPU is idle, investigate write cache policy, controller cache, and firmware/driver resets.

Task 6: Confirm TRIM/ReTrim behavior (SSDs) and whether Windows thinks it’s an SSD

cr0x@server:~$ fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0
ReFS DisableDeleteNotify = 0

Meaning: 0 means TRIM is enabled. If TRIM is disabled on SSD-backed volumes, long-term write performance can degrade.

Decision: If you see sustained write cliff behavior over weeks/months, verify TRIM and device firmware GC behavior.

Task 7: Check the power plan that silently caps performance

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Meaning: Balanced can be okay, but on some servers it causes frequency scaling and latency variability that looks like “random slowness.”

Decision: For performance-critical servers, move to High performance (after validating thermals) or explicitly tune processor minimum state.

Task 8: Verify CPU frequency isn’t stuck low (thermal/power limit)

cr0x@server:~$ wmic cpu get name, currentclockspeed, maxclockspeed
CurrentClockSpeed  MaxClockSpeed  Name
1896               3500           Intel(R) Xeon(R) Silver ...

Meaning: If current clock is far below max under load, you may be power-limited, thermally throttled, or on an aggressive power policy.

Decision: Correlate with load; if under load it’s still low, check BIOS power limits, cooling, and Windows power settings.

Task 9: Check PCIe device presence and problem codes

cr0x@server:~$ pnputil /enum-devices /problem /class System
Instance ID: PCI\VEN_8086&DEV_2030&SUBSYS_...
Problem: 0000000A (CM_PROB_FAILED_START)

Meaning: Devices with problem codes aren’t “kinda working.” They’re not working. Sometimes Windows falls back to generic paths.

Decision: Fix driver binding and firmware settings before performance tuning. You can’t optimize a device that didn’t start.

Task 10: Inspect NIC link state and speed

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed, DriverInformation"
Name   Status  LinkSpeed DriverInformation
Ethernet0 Up   1 Gbps    Intel(R) Ethernet Controller X710 ...

Meaning: If you expected 10/25/40/100GbE and you’re at 1Gbps, stop everything else. That’s your bottleneck.

Decision: Check switch port configuration, cabling/transceiver, and NIC advanced properties. Don’t blame TCP.

Task 11: Check for NIC offload features that can help or hurt

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet0 | Where-Object {$_.DisplayName -match 'RSS|RSC|LSO|Checksum'} | Select-Object DisplayName, DisplayValue"
DisplayName                 DisplayValue
Receive Side Scaling        Enabled
Receive Segment Coalescing  Enabled
Large Send Offload v2 (IPv4) Enabled
IPv4 Checksum Offload       Rx & Tx Enabled

Meaning: Offloads can reduce CPU and increase throughput, but can add latency or trigger driver/firmware edge cases.

Decision: If you have latency spikes or weird retransmits, test toggling one feature at a time with a rollback plan.

Task 12: Look for DPC/ISR pressure (classic driver bottleneck)

cr0x@server:~$ typeperf "\Processor(_Total)\% DPC Time" "\Processor(_Total)\% Interrupt Time" -sc 5
"(PDH-CSV 4.0)","\\server\Processor(_Total)\% DPC Time","\\server\Processor(_Total)\% Interrupt Time"
"1.000000","12.482931","6.193847"
"1.000000","14.110332","7.003218"
"1.000000","11.802104","6.552190"
"1.000000","13.224987","6.990114"
"1.000000","12.901443","6.401008"

Meaning: High DPC/interrupt time usually means a driver is making the CPU do too much “interrupt work,” starving normal threads. Network and storage drivers are common culprits.

Decision: If DPC/Interrupt are persistently high under moderate load, focus on NIC/storage driver versions, interrupt moderation, RSS configuration, and firmware.

Task 13: Confirm VBS/HVCI status (security features that can change performance)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Meaning: Non-empty output indicates security services (like Credential Guard and/or HVCI) are running. This is not “bad,” but it’s a variable you must account for.

Decision: If performance regressed after a hardening baseline change, test in a controlled environment with and without the feature set. Don’t guess.

Task 14: Check storage write cache policy (dangerous knob, treat carefully)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, IsWriteCacheEnabled"
FriendlyName        MediaType  BusType IsWriteCacheEnabled
NVMeDisk0           SSD        NVMe    True
SATADisk1           HDD        SATA    False

Meaning: If write cache is disabled on a device you expect to be fast, write latency will be ugly. If it’s enabled without power-loss protection, you may be fast and wrong.

Decision: Only change write caching if you understand durability requirements and the hardware’s power-loss protection. Otherwise you’re trading performance for data integrity.

Task 15: Validate device reset and PCIe errors in the event logs

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  ...
  Description: A corrected hardware error has occurred.

Meaning: Corrected WHEA errors often indicate PCIe link issues, marginal hardware, or signal integrity problems. “Corrected” still costs performance and can foreshadow uncorrected failures.

Decision: If WHEA 17/19 correlates with performance drops, inspect PCIe seating, backplane, risers, BIOS PCIe settings, and device firmware. This is not an application bug.

Broma #2: Lo único más optimista que “probablemente está bien” es “probablemente es DNS”.

Tres microhistorias corporativas desde la trinchera

1) Incidente causado por una suposición errónea: “BIOS configura la velocidad de la NIC, ¿verdad?”

Una empresa mediana desplegó un nuevo rack de hosts Windows Server para un servicio interno sensible a la latencia. El plan de despliegue era limpio: hardware idéntico, perfil BIOS idéntico, instalación automatizada del SO y una prueba de humo rápida. La prueba de humo pasó: CPU, memoria y disco parecían normales.

Luego llegó el tráfico de producción. La latencia se duplicó. El rendimiento se aplanó. Las gráficas parecían un cuello de botella clásico de CPU, excepto que la utilización de CPU era sospechosamente baja. La gente hizo lo que hace la gente: discutió en círculos sobre si era “la aplicación”.

La suposición fue que el BIOS “configura la NIC” y por tanto la NIC debía estar bien. Un rápido Get-NetAdapter rompió esa ilusión: las NIC negociaron a 1Gbps en lugar de la velocidad esperada mayor. El perfil BIOS era irrelevante; la negociación de enlace era entre la NIC y el switch. Algunos puertos estaban fijados a una velocidad/duplex inesperada debido a una plantilla heredada del switch.

La solución fue aburrida: corregir la configuración del puerto del switch, verificar transceptores y confirmar la velocidad de enlace en cada host como parte de la puesta en marcha. La lección no fue “equipo de red culpable”. Fue: BIOS no posee la negociación de enlace. El controlador informa lo que el PHY negoció, y Windows usa esa realidad.

Después añadieron una verificación de validación preproducción: si la velocidad de enlace no es la esperada, no despliegue. Esa comprobación previno una repetición cuando el siguiente rack llegó con un lote distinto de transceptores.

2) Optimización que salió mal: “Activen todos los offloads, es rendimiento gratis”

Otra organización tenía un pipeline de ingestión de archivos en Windows que consumía demasiada CPU. Alguien, intentando ayudar, activó un conjunto de offloads de NIC en toda la flota: large send, coalescencia de recepción, checksum offloads y algunas mejoras específicas del proveedor. El uso de CPU bajó. Todos celebraron. Se cerró un ticket con un comentario satisfecho y sin plan de medición posterior.

Dos semanas después, incidente: paradas intermitentes y retransmisiones, pero solo bajo ciertos patrones de tráfico. El monitoreo mostró picos periódicos en tiempo DPC y latencia de red. El almacenamiento parecía bien. Los logs de la aplicación estaban ruidosos pero poco útiles.

La causa raíz fue una interacción entre una versión específica del controlador y una característica offload bajo un perfil particular de paquetes. No falló estruendosamente; degradó. Windows no fue “culpable”, pero Windows fue el escenario donde se representó la falla: presión DPC, procesamiento retrasado y timeouts más arriba en la pila.

La solución no fue “desactivar todo para siempre”. Fue: fijar versiones de controladores, probar configuraciones de offload bajo carga representativa y desplegar incrementos. Al final dejaron la mayoría de offloads activados pero deshabilitaron el problemático, además de programar una actualización de controlador/firmware en una ventana de mantenimiento.

Moral: los controles de rendimiento son como las especias. Un poco es genial. Vaciar el frasco entero y se arrepentirá.

3) Práctica aburrida pero correcta que salvó el día: “Instantáneas de línea base antes y después”

Una gran empresa ejecutaba hosts Windows con una mezcla de almacenamiento NVMe y respaldado por RAID. Tenían una práctica que parecía dolorosamente burocrática: cada cambio de plataforma requería capturar un paquete de línea base—inventario de controladores, contadores de rendimiento clave y una breve prueba sintética de I/O. Estaba automatizado y almacenado con el registro de cambio.

Un trimestre, un conjunto de hosts empezó a ver reinicios sporádicos de Storport (Event ID 129) y picos de latencia de escritura. La primera reacción fue culpar a la última actualización acumulativa de Windows. Esa teoría era emocionalmente satisfactoria y técnicamente plausible.

Las instantáneas de línea base hicieron corta la discusión. Comparar el “antes” y el “después” en hosts afectados mostró: la build de Windows era la misma entre máquinas sanas y enfermas, pero la revisión de firmware NVMe difería. Un proveedor había enviado nuevo firmware en una renovación de la cadena de suministro, y se comportaba distinto bajo presión sostenida de escrituras.

Porque tenían evidencia, no tuvieron que adivinar. Segmentaron la flota por revisión de firmware, confirmaron la correlación y programaron una remediación de firmware dirigida. Mientras tanto ajustaron la colocación de cargas para reducir la presión en nodos afectados.

La práctica aburrida—líneas base consistentes—no solo ahorró tiempo. Evitó un rollback de un parche de seguridad que no era realmente responsable.

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

1) “El disco está lento” durante benchmarks, pero las apps van bien

Síntoma: Benchmarks sintéticos de disco muestran resultados inconsistentes; las cargas reales no se ven afectadas de forma obvia.

Causa raíz: Caché del sistema de archivos y comportamiento de escritura diferida; el benchmark mide RAM o vaciado de caché, no el dispositivo.

Solución: Use metodología de prueba consistente; observe Avg. Disk sec/* y la longitud de cola, y ejecute pruebas que omitan caché cuando corresponda (o al menos vacíe entre ejecuciones). Compare contra contadores de rendimiento, no solo MB/s.

2) Ancho de banda de red limitado exactamente a 1Gbps (o 10Gbps) en hardware “más rápido”

Síntoma: El rendimiento alcanza un techo rígido; CPU baja; sin errores.

Causa raíz: Negociación de enlace o perfil de puerto de switch incorrecto; cable/transceptor equivocado; a veces NIC en modo forzado.

Solución: Compruebe Get-NetAdapter para la velocidad de enlace; valide la configuración del switch y la capa física; evite pensar “debe ser Windows”.

3) Bloqueos aleatorios de E/S con reinicios de Storport

Síntoma: Event ID 129 en ráfagas; picos de latencia; a veces “hangs” temporales.

Causa raíz: Timeouts del controlador de almacenamiento, recuperación de errores por firmware, problemas de señal PCIe o problemas de caché del controlador.

Solución: Correlacione logs de evento con latencia; actualice controlador y firmware de dispositivo en una ventana controlada; inspeccione cableado/backplane/riser; revise errores WHEA corregidos.

4) Rendimiento empeora tras “endurecimiento de seguridad”

Síntoma: Aumenta la sobrecarga de CPU; la latencia de I/O es más variable; a veces mayor cambio de contexto.

Causa raíz: VBS/HVCI/Device Guard cambian el comportamiento del kernel y las restricciones de ejecución de controladores; algunos controladores rinden peor bajo estas restricciones.

Solución: Mida con y sin las características en un entorno de staging; actualice controladores certificados para esa postura de seguridad; no desactive seguridad en producción como primera opción.

5) CPU parece infrautilizada pero el sistema está “lento”

Síntoma: Bajo porcentaje de CPU, altos tiempos de respuesta, tartamudeos intermitentes.

Causa raíz: Alto tiempo DPC/interrupción; tormentas de interrupciones por controladores; RSS pobre; interrupciones de almacenamiento ancladas a un núcleo.

Solución: Compruebe % DPC Time y % Interrupt Time; actualice/ajuste controladores NIC/almacenamiento; configure RSS; ajuste moderación de interrupciones con cuidado.

6) NVMe “unidad rápida” rinde como SATA

Síntoma: IOPS/ancho de banda inferiores a lo esperado; alta latencia bajo carga.

Causa raíz: Enlace PCIe entrenado a menor ancho (x1, Gen1/Gen2); limitación térmica; problemas de estados de energía.

Solución: Revise errores WHEA; verifique ajustes PCIe en BIOS; confirme refrigeración; valide el controlador; compruebe rendimiento sostenido en lugar de picos cortos.

7) “La caché del controlador RAID lo hace rápido” y luego susto por pérdida de datos

Síntoma: Gran rendimiento de escritura hasta un evento de pérdida de energía; la recuperación tarda mucho; posible corrupción.

Causa raíz: Caché write-back habilitada sin protección por batería/flash; el SO asume durabilidad que no fue entregada.

Solución: Asegure que la protección de caché exista y esté sana; alinee la política de caché de Windows con las capacidades del controlador; no intercambie corrección por velocidad sin aprobación.

Listas de verificación / plan paso a paso

Checklist A: Antes de tocar ajustes BIOS/UEFI

1. Capture la versión actual de BIOS (wmic bios) y exporte la configuración BIOS si la herramienta del proveedor lo permite.
2. Registre la build de Windows y el inventario de controladores (systeminfo, driverquery).
3. Recolecte muestras de registros de eventos: Storport, WHEA y proveedores de dispositivo relevantes.
4. Ejecute una línea base corta: contadores de latencia de disco, contadores DPC/Interrupt, velocidad de enlace NIC.
5. Defina rollback: cómo revertir ajustes de BIOS, cómo recuperar si el sistema no arranca.

Checklist B: Plan de cambio de controlador controlado (la forma sensata)

1. Identifique el controlador cargado y su versión (driverquery /v).
2. Cambie un componente a la vez (controlador NIC o controlador de almacenamiento, no ambos).
3. Despliegue a un pequeño canario con carga representativa.
4. Mida: throughput, latencia, tiempo DPC/Interrupt, registros de eventos.
5. Promueva gradualmente; mantenga un paquete de controlador conocido-bueno listo para rollback.

Checklist C: Aislamiento de cuello de botella de almacenamiento en 30 minutos

1. Compruebe reinicios/timeouts de Storport (Event 129/153/157).
2. Mida Avg. Disk sec/Read, Avg. Disk sec/Write, longitud de cola.
3. Compruebe el estado de caché de escritura (Get-PhysicalDisk) y confirme supuestos de durabilidad.
4. Busque errores WHEA corregidos alrededor de los mismos tiempos.
5. Si hay desajuste firmware/controlador entre hosts, segmente y compare.

Checklist D: Aislamiento de cuello de botella de red en 30 minutos

1. Confirme la velocidad de enlace negociada (Get-NetAdapter).
2. Mida tiempo DPC/Interrupt; correlacione con caídas de throughput.
3. Revise configuraciones de offload; compare con un host conocido-bueno.
4. Busque reinicios de controladores o advertencias en el registro System.
5. Escale a la capa física (switch/transceptores/cableado) si la velocidad de enlace está mal.

FAQ

1) ¿El BIOS controla mi rendimiento de almacenamiento después del arranque?

Usualmente no de forma directa. BIOS establece condiciones iniciales (enlace PCIe, ACPI, modo de la controladora). Tras el arranque, el driver de almacenamiento + el firmware del dispositivo dominan el comportamiento.

2) Si actualizo un controlador, ¿necesito también actualizar firmware?

No siempre, pero debe tratar controlador y firmware como un par para dispositivos críticos (NICs, HBAs, NVMe). Muchos “bugs de controlador” son interacciones con firmware.

3) ¿Por qué veo Event ID 129 de Storport pero los discos parecen sanos?

Porque “sano” en términos SMART aún puede incluir timeouts y reinicios. Event 129 trata sobre timeouts de I/O y recuperación, que pueden ocurrir con enlaces PCIe marginales, stalls de firmware o problemas de controlador.

4) ¿Es malo el controlador inbox de Microsoft?

No. Los controladores inbox suelen ser sólidos y estables. Pero los controladores de proveedor pueden exponer ajustes, offloads o telemetría que necesite. Use el controlador que coincida con sus requisitos y pruébelo.

5) ¿Realmente las configuraciones de energía de Windows pueden afectar rendimiento de servidor?

Sí. Los planes de energía y las políticas de inactividad de dispositivos influyen en el comportamiento de frecuencia de CPU y a veces en estados de energía PCIe. Si necesita latencia predecible, valide explicitamente su configuración de energía.

6) ¿Cómo sé si estoy limitado por interrupciones?

Compruebe % DPC Time y % Interrupt Time con typeperf. Si están altos y correlacionan con problemas de throughput o latencia, un controlador suele ser el cuello de botella.

7) ¿Por qué difiere el rendimiento entre servidores “idénticos”?

Porque rara vez son idénticos: diferentes revisiones de firmware, distintas versiones de controladores, cableado de ranuras PCIe diferente, valores por defecto de BIOS distintos, puertos de switch distintos o entornos térmicos diferentes.

8) ¿Debería cambiar ajustes BIOS durante un incidente?

Sólo si puede explicar la cadena causal y tiene un plan de rollback. De lo contrario, recopile evidencia primero y programe cambios de firmware en una ventana de mantenimiento.

9) ¿Cómo evito que las pruebas de disco me engañen por la caché?

Observe contadores de latencia y colas, no solo throughput. Use tamaños de prueba consistentes y repita ejecuciones. Trate resultados “demasiado buenos para ser verdad” como sospechosos hasta probarlos.

Próximos pasos que puede hacer esta semana

Deje de tratar “BIOS vs controlador vs Windows” como un debate filosófico. Es un problema de límites de control. Los equipos más rápidos ganan probando cuál capa posee el síntoma y luego haciendo un cambio reversible a la vez.

1. Automatice un paquete de línea base: versión de BIOS, build de Windows, controladores cargados, velocidad de enlace NIC, contadores de rendimiento clave y extractos de registros de eventos.
2. Añada dos comprobaciones de puesta en marcha a cada host nuevo: velocidad de enlace NIC esperada y ausencia de inundaciones de errores WHEA corregidos.
3. Construya una matriz de controladores/firmware para dispositivos críticos y fije versiones. “Último” no es una estrategia; es una esperanza.
4. Practique la guía de diagnóstico rápido en un sistema sano para no aprender comandos durante un incidente.

Si no hace nada más: convierta el inventario de controladores cargados y las comprobaciones de registros de eventos en parte de su memoria muscular de primera respuesta. La mayoría de “misterios de hardware” se vuelven muy normales una vez que mira qué está pasando realmente.