Por qué Windows y Linux pueden ofrecer FPS diferentes en la misma CPU

Los FPS son un síntoma; el tiempo por frame es la enfermedad

“FPS diferentes” suele ser una forma abreviada de un conjunto de problemas separados:

• FPS promedio (fácil de presumir, fácil de manipular con benchmarks).
• Lowest 1% / 0.1% (qué tan mal se pone cuando el SO y los controladores interfieren con tu carga).
• Pacing de frames (entrega consistente de frames frente a un desastre con jitter).
• Latencia entrada→fotón (cuánto tarda tu clic en convertirse en un píxel).

Dos sistemas pueden tener FPS promedio idénticos y aun así sentirse radicalmente distintos porque uno tiene una distribución del tiempo por frame más ajustada. El SO importa porque el SO decide quién corre cuándo, en qué núcleo, a qué frecuencia y con qué interrupciones irrumpiendo en el peor momento posible.

Mentalidad operativa: un frame del juego es una pequeña línea de producción. Tienes un hilo principal, hilos de renderizado, hilos worker, envío al driver, ejecución en GPU, present, composición y a veces capas de traducción. Si cualquier etapa se atasca, toda la tubería hace un bache.

El SO es el gestor de la tubería. Gestor distinto, cuellos de botella distintos.

Datos interesantes y contexto histórico

Esto no es trivia por trivia. Explica por qué algunas decisiones de diseño existen y por qué son tercamente difíciles de “arreglar” hoy en día.

1. Las APIs de juegos de Windows moldearon las prioridades de los controladores. DirectX dominó el juego de PC durante décadas, y los proveedores optimizaron controladores y herramientas para Windows en consecuencia.
2. El gráfico en Linux pasó por varias eras. El modelo de X11, luego compositores, luego Wayland; cada cambio mejoró algunas rutas de latencia y complicó otras.
3. El planificador de Windows se ha afinado para la interactividad de escritorio durante mucho tiempo. El refuerzo de primer plano y la planificación multimedia existen porque las aplicaciones de escritorio (y luego los juegos) necesitaban capacidad de respuesta.
4. El CFS de Linux optimizó equidad y rendimiento. Es excelente para cargas mixtas, pero “equitativo” no siempre significa “menor latencia ahora mismo”.
5. Los temporizadores de alta resolución cambiaron la depuración de rendimiento. A medida que los temporizadores se hicieron más precisos, los desarrolladores empezaron a recurrir a busy-waiting y polling de alta frecuencia; eso es una granada para el consumo de energía y la planificación.
6. Los CPUs modernos forzaron complejidad en políticas de energía a nivel de SO. Turbo, E-cores/P-cores, CPPC, estados C profundos—estos añaden puntos de decisión donde los valores predeterminados del SO divergen.
7. Los modelos de controlador difieren. WDDM de Windows enfatiza preempción, planificación y control a nivel de SO; Linux tiene una división distinta entre DRM en el kernel, Mesa y blobs de proveedores.
8. “Pantalla completa exclusiva” se volvió un campo de batalla. Windows introdujo “optimizaciones de pantalla completa” para reducir cambios de modo; a veces genial, otras veces terrible. Las reglas de composición en Linux son diferentes otra vez.

De dónde vienen las diferencias del SO (la lista real)

1) Planificación de CPU: quién corre, dónde y por cuánto tiempo

Los juegos no son uniformemente paralelos. Muchos siguen limitados por un hilo principal o un par de hilos calientes con orden estricto. Eso hace que las decisiones de planificación sean visibles.

• Windows tiene un conjunto maduro de heurísticas para aplicaciones en primer plano, planificación de clase multimedia y “dar más oportunidades al elemento activo”. No es perfecto, pero es intencional.
• Linux con CFS es extremadamente bueno en equidad y utilización. Pero equidad puede significar que tu hilo caliente comparta tiempo más “democráticamente” con trabajo en segundo plano que no sabías que importaba (como un compositor, una pestaña del navegador o un constructor de caché de sombreado).

Cuando ves picos en el tiempo por frame cada pocos segundos, sospecha interferencia de planificación: un hilo del kernel, una tormenta de interrupciones, un evento de recuperación de memoria o un servicio en segundo plano haciendo trabajo “útil”.

2) Gestión de energía: turbo, gobernadores y el impuesto de latencia

Las diferencias en la política de energía son una de las razones más comunes por las que la misma CPU se comporta distinto.

• En Linux, puedes quedar atrapado en powersave o una EPP conservadora (energy performance preference) y nunca alcanzar las frecuencias que esperas.
• En Windows, “Equilibrado” a menudo aún impulsa agresivamente en sistemas modernos, pero utilidades del fabricante pueden anular esto, y el firmware del portátil puede limitar la potencia sostenida.

La gestión de energía no es solo “menos FPS”. Puede ser jitter: despertar núcleos desde estados C profundos, subir la frecuencia tarde, aparcar/desaparcar núcleos y migrar hilos entre núcleos con cachés frías.

Opinión: para pruebas de rendimiento, no midas con “equilibrado”. Pásalo a modo rendimiento y elimina la incertidumbre primero. Luego baja la energía intencionadamente.

3) Resolución de temporizador y precisión de sleep

Los juegos dependen de dormir, esperar y pacing. La diferencia entre un wakeup de 1ms y uno de 15.6ms es la diferencia entre “suave” y “¿por qué se siente como puré?”

Windows hace tiempo que tiene el concepto de resolución del temporizador del sistema que las aplicaciones pueden solicitar. Linux también tiene temporizadores de alta resolución, pero el comportamiento depende de la configuración del kernel, la tasa de tick y de si algo impide que la CPU entre en inactividad.

Traducción: dos SO pueden ejecutar el mismo código y discrepar sobre lo que significa “dormir 1ms” bajo carga.

4) Pila gráfica y sobrecarga de controladores

En Windows, la mayoría de los juegos nativos están ajustados para DirectX y el comportamiento de WDDM. En Linux, podrías usar:

• Vulkan nativo
• OpenGL
• Proton/Wine + DXVK (D3D9/10/11 → Vulkan)
• vkd3d-proton (D3D12 → Vulkan)

Cada capa de traducción tiene sobrecarga en CPU y comportamiento de caché. Puede ser mínima, o puede quemar varios milisegundos por frame en el peor caso (compilación de sombreadores, traducción de estados, rarezas de sincronización).

5) Compositores, gestores de ventanas y rutas de present

En Windows, DWM siempre está presente, pero la ruta de present difiere entre sin bordes, pantalla completa exclusiva y “optimizaciones de pantalla completa”. En Linux, tratas con X11 vs Wayland, además de las políticas del compositor (KWin, Mutter, etc.).

La composición puede añadir latencia, introducir buffers extra o forzar sincronización en puntos incómodos. O puede ocultar tearing y suavizar el pacing. La clave es: tu entorno de escritorio es parte de la tubería de renderizado.

6) Manejo de interrupciones y comportamiento DPC/softirq

Las interrupciones son pequeñas emergencias. Demasiadas, o mal ubicadas, y tu hilo principal pierde rebanadas de tiempo justo cuando las necesita.

• Windows lo muestra como problemas de latencia DPC, a menudo ligados a controladores (red, audio, almacenamiento, utilidades RGB—sí, en serio).
• Linux lo muestra como tiempo de softirq, despertares de ksoftirqd, problemas de afinidad de IRQ o módulos de kernel que se comportan mal.

Si tus FPS caen mientras descargas algo, transmites o usas audio Bluetooth, probablemente estás viendo interrupciones y planificación de controladores.

7) Gestión de memoria y reclaim en segundo plano

Ambos SO tienen sistemas VM sofisticados. Ambos pueden dañarte. Linux puede decidir que es buen momento para recuperar memoria o compactar páginas. Windows puede decidir que es buen momento para indexar, escanear o actualizar apps de la tienda. Los detalles difieren, pero el modo de fallo se parece: stalls aleatorios de 30–200ms.

Los juegos que transmiten assets agresivamente son sensibles al comportamiento del page cache y al scheduling de E/S. Si además ejecutas navegadores, lanzadores y overlays, has creado un pequeño sistema distribuido—en una caja.

8) Comportamiento del sistema de archivos y pila de almacenamiento

Sí, el almacenamiento puede afectar los FPS—especialmente los picos en el tiempo por frame—porque los juegos modernos transmiten texturas, sombreadores y geometría. NTFS en Windows vs ext4/btrfs/xfs en Linux no es solo rendimiento bruto. Es políticas de caché, sobrecarga de metadatos, tareas en segundo plano (como scrub de btrfs) y la pila de controladores NVMe.

Opinión: si diagnosticas stutter, trata el almacenamiento como sospechoso de primera clase. Los picos de tiempo por frame a menudo se correlacionan con esperas de E/S.

9) Funciones de seguridad y mitigaciones

Las mitigaciones del kernel para vulnerabilidades de ejecución especulativa y características de hardening pueden cambiar el costo de syscalls, la sobrecarga de cambio de contexto y el comportamiento de barreras de memoria.

A veces el impacto es insignificante. A veces es la diferencia entre “CPU-limited” y “GPU-limited”. La única respuesta honesta es: mide con tu carga de trabajo.

10) Utilidades del proveedor y software “útil”

En Windows: demonios de energía de OEM, suites de audio, grabadores de overlay, controladores RGB, telemetría de placa base. En Linux: extensiones de escritorio, indexación en segundo plano, demonios de energía, herramientas laptop-mode, módulos de kernel fuera del árbol.

Nada de esto es inherentemente malo. Pero cada servicio residente es candidato a jitter.

Una frase que vale la pena pegar en tu monitor: “La esperanza no es una estrategia.” — General Gordon R. Sullivan

Esa línea es útil operativamente porque te obliga a dejar de adivinar. Haz benchmarks, perfila y cambia una variable a la vez.

Broma #1: Si no puedes reproducir el stutter, felicidades—has construido un benchmark cuántico. Observarlo lo cambió.

Playbook de diagnóstico rápido

Este es el orden de triaje que uso cuando alguien dice “Linux da menos FPS que Windows en la misma CPU” o “Windows se siente con stutter pero Linux es fluido.” No es filosófico. Es lo que encuentra el cuello de botella rápido.

Primero: confirma qué tipo de problema tienes

• Si el FPS promedio es menor: sospecha política de energía, sobrecarga del driver, capas de traducción o límites de frecuencia de CPU.
• Si los lowest 1% son peores (picos): sospecha tareas en segundo plano, interrupciones, reclaim de memoria, compilación de sombreadores, esperas de E/S, composición o problemas de VRR/present.
• Si la latencia de entrada es peor: sospecha buffering, composición, modos de vsync y profundidad de cola en la pila gráfica.

Segundo: determina CPU vs GPU vs E/S

• Limitado por GPU: GPU en alta utilización; bajar resolución aumenta poco los FPS; la CPU tiene margen.
• Limitado por CPU: uno o dos núcleos calientes; bajar resolución ayuda poco; frecuencias de CPU más altas ayudan mucho.
• Limitado por E/S: los picos en el tiempo por frame se correlacionan con lecturas de disco, fallos de página o escrituras de caché de sombreado.

Tercero: elimina ruido, luego vuelve a añadir

• Desactiva overlays y grabadores.
• Usa un perfil de energía fijo.
• Prueba un modo de ventana distinto (exclusivo/sin bordes) y ajustes del compositor.
• Mide otra vez. Solo entonces empieza a ajustar cosas avanzadas como afinidad de IRQ.

Tareas prácticas: comandos, salidas y decisiones

Estas tareas están escritas como runbooks de SRE: comando, qué podrías ver, qué significa y qué haces después. La mayoría de los ejemplos son de Linux porque es introspectable sin herramientas de terceros, pero algunas verificaciones de Windows también importan.

Task 1: Confirmar comportamiento de frecuencia de CPU (Linux)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 5800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              3387.000

Qué significa: CPU MHz es una instantánea, no la verdad absoluta. Pero te dice si estás atascado en relojes bajos.

Decisión: Si las frecuencias parecen bajas bajo carga, revisa el governor/EPP a continuación.

Task 2: Comprobar governor y EPP (Linux)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_power

Qué significa: Le estás diciendo a la CPU “ahorra energía” y luego te preguntas por qué no acelera.

Decisión: Para pruebas, cambia a performance (o ajusta EPP a performance) y vuelve a ejecutar el benchmark.

Task 3: Poner governor de rendimiento temporalmente (Linux)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

Qué significa: Estás reduciendo la latencia de rampa de frecuencia y elevando relojes sostenidos.

Decisión: Si los FPS mejoran notablemente, tu “diferencia de SO” era mayormente política de energía.

Task 4: Verificar que turbo/boost esté activo (Linux, ejemplo Intel)

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
0

Qué significa: 0 significa que turbo está permitido.

Decisión: Si es 1, habilita turbo y vuelve a probar. Si no puedes, revisa BIOS o límites OEM de potencia.

Task 5: Capturar ladrones de CPU en segundo plano (Linux)

cr0x@server:~$ top -o %CPU -b -n 1 | head -n 15
top - 10:41:02 up  3:12,  1 user,  load average: 2.31, 1.88, 1.25
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.4 us,  2.1 sy,  0.0 ni, 84.9 id,  0.4 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2441 cr0x      20   0 6729348 688144 212000 R  95.0   4.3   2:10.31 game.bin
1882 cr0x      20   0 1492256 102332  52944 S  12.0   0.6   0:20.02 shadercache
1120 root      20   0       0      0      0 S   4.3   0.0   0:11.55 kswapd0

Qué significa: Si ves kswapd0 o intensa actividad de caché de sombreado durante el juego, espera picos.

Decisión: Si la presión de memoria es real, añade RAM o reduce apps en segundo plano. Si la compilación de sombreadores está en curso, precalienta caches o espera a que termine la primera ejecución.

Task 6: Comprobar presión de memoria y reclaim (Linux)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512348  82344 6021840   0    0    12    55 3210 8120 18  3 79  0  0
 1  0      0 498120  82344 6030100   0    0     0   102 3120 7900 21  4 75  0  0
 3  1      0  88240  82344 6029900   0    0  5120  4200 9800 22000 35  8 49  8  0
 2  1      0  70120  82344 6028800   0    0  6200  3900 10200 24500 32 10 46 12  0
 1  0      0 110220  82344 6029200   0    0   140   180 4100 9000 20  4 76  0  0

Qué significa: La columna b (bloqueado), más picos en wa (I/O wait) y fuerte bi/bo, sugiere stalls probables visibles como picos en el tiempo por frame.

Decisión: Si ves esto durante las caídas, investiga almacenamiento y ubicación de caché de sombreado; asegúrate de que el juego esté en un SSD rápido; revisa sistema de archivos y espacio libre.

Task 7: Identificar stalls de E/S (Linux)

cr0x@server:~$ iostat -xz 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    4.80    6.30    0.00   66.80

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         180.0   8200.0     2.0   1.10    5.40    45.6     90.0   6100.0    9.80    67.8    1.22  92.0

Qué significa: Alto %util y r_await/w_await elevados durante el stutter = almacenamiento es parte de la historia del tiempo por frame.

Decisión: Mueve el juego y la caché de sombreado al SSD más rápido, asegúrate de que no haya scrubs/índices/descargas en segundo plano; revisa throttling térmico en el NVMe.

Task 8: Detectar estrangulamiento térmico (Linux)

cr0x@server:~$ sensors | egrep 'Tctl|Package|Core|Composite'
Tctl:         +87.5°C
Package id 0:  +91.0°C
Composite:     +78.2°C

Qué significa: Altas temperaturas pueden disparar reducciones de reloj. Algunos sistemas limitan la CPU, otros la GPU, algunos silenciosamente ambos.

Decisión: Si las temperaturas están cerca de puntos de throttling durante benchmarks, arregla la refrigeración, curvas de ventilador, polvo, presión de montaje o límites de potencia del portátil antes de culpar al SO.

Task 9: Confirmar driver de GPU y ruta de render (Linux)

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 4070/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Qué significa: Estás en el driver GPU previsto, no en un renderer de respaldo.

Decisión: Si ves LLVMpipe o una GPU equivocada, arregla la instalación del driver, ajustes PRIME offload o la selección del dispositivo.

Task 10: Comprobar selección de dispositivo Vulkan (Linux)

cr0x@server:~$ vulkaninfo --summary | egrep 'GPU id|deviceName|driverName|apiVersion' -m 8
GPU id : 0 (NVIDIA GeForce RTX 4070)
driverName = NVIDIA
apiVersion = 1.3.280
GPU id : 1 (AMD Radeon(TM) Graphics)
driverName = RADV
apiVersion = 1.3.275

Qué significa: Sistemas multi-GPU pueden elegir el dispositivo equivocado (iGPU vs dGPU), especialmente en portátiles.

Decisión: Si el juego corre en la iGPU, fuerza la dGPU mediante variables de entorno o tu método de cambio gráfico, y vuelve a probar.

Task 11: Comprobar compositor / tipo de sesión (Linux)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
cr0x@server:~$ echo $XDG_CURRENT_DESKTOP
GNOME

Qué significa: Wayland vs X11 puede cambiar latencia y comportamiento VRR dependiendo del compositor y drivers.

Decisión: Si estás diagnosticando stutter, prueba sesiones Wayland y X11 (una a la vez). Toma notas.

Task 12: Vigilar carga de IRQ y softirq (Linux)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:         22          0          0          0          0          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0          0          0          0          0   IO-APIC   1-edge      i8042
 24:      88210       1200        980       1100       1050       1001       1122       1088   PCI-MSI 327680-edge      nvme0q0
 32:     190220       3100       2990       3050       3010       2975       3090       3002   PCI-MSI 524288-edge      nvidia

Qué significa: Un solo CPU recibiendo la mayoría de interrupciones puede causar jitter localizado si el hilo caliente del juego también cae ahí.

Decisión: Si un núcleo es imán de interrupciones, considera configurar el balanceo de IRQ o aislar el juego lejos de ese núcleo (avanzado; prueba con cuidado).

Task 13: Comprobar carga por núcleo y sospecha de migración (Linux)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.8 (server) 	01/10/2026 	_x86_64_	(16 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %idle
12:10:02 PM  all   24.2    0.0    5.1    1.2    0.0    0.7   68.8
12:10:02 PM    0   12.0    0.0    3.0    0.0    0.0    6.0   79.0
12:10:02 PM    5   78.0    0.0    5.0    0.0    0.0    0.0   17.0
12:10:02 PM    6   65.0    0.0    6.0    0.0    0.0    0.0   29.0

Qué significa: Uno o dos núcleos calientes son típicos para el hilo principal del juego; pero si el núcleo caliente cambia constantemente, puedes pagar costos de miss de caché y migración.

Decisión: Si la migración se correlaciona con picos, prueba con afinidad de CPU para el proceso del juego (con cuidado; no lo hagas por inercia).

Task 14: Comprobar indicadores de latencia de planificación del kernel (Linux)

cr0x@server:~$ cat /proc/schedstat | head -n 5
version 15
timestamp 18273648590
cpu0 0 0 0 0 0 0 1234567890 0 0
cpu1 0 0 0 0 0 0 1134567890 0 0
domain0 0 0 0 0 0 0 0 0 0

Qué significa: Este archivo es crudo, pero es una canaria: si vas profundo, mides planificación y comportamiento de runqueue, no adivinas.

Decisión: Usa esto solo si estás listo para perfilar con perf. Si no, quédate con indicadores de más alto nivel.

Task 15: Perfilar hotspots de CPU rápidamente (Linux)

cr0x@server:~$ sudo perf top -g --call-graph fp
Samples: 5K of event 'cycles', 4000 Hz, Event count (approx.): 1200000000
  22.15%  game.bin             [.] UpdateWorld
  14.02%  libnvidia-glcore.so   [.] glDrawElements
   9.88%  dxvk-native.so        [.] dxvk::Presenter::present
   6.41%  [kernel]              [k] schedule

Qué significa: Puedes ver si estás limitado por CPU en código del juego, sobrecarga de driver, capa de traducción o pasando tiempo en planificación.

Decisión: Si el planificador del kernel aparece prominente, reduce carga de fondo e interrupciones. Si driver/traducción domina, prueba versiones de driver distintas o una ruta API nativa.

Task 16: Detectar uso de swap (Linux)

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file  16G  2G   -2

Qué significa: El uso de swap durante una sesión de juego puede causar stalls periódicos, especialmente en almacenamiento más lento.

Decisión: Si el swap es significativo mientras juegas, reduce la presión de memoria: cierra apps, añade RAM o ajusta swappiness (y verifica que no estés ocultando una carencia real de RAM).

Task 17: Encontrar fallos de página durante el juego (Linux)

cr0x@server:~$ pidof game.bin
2441
cr0x@server:~$ ps -o pid,comm,min_flt,maj_flt,rss,vsz -p 2441
  PID COMMAND   MINFLT  MAJFLT    RSS     VSZ
 2441 game.bin  912345     210 6812200 6820000

Qué significa: Fallos mayores (maj_flt) implican fetches desde disco—a menudo visibles como stutter si ocurren en medio de una acción.

Decisión: Si los fallos mayores aumentan durante las caídas, revisa presión de memoria, comportamiento de streaming de assets y rendimiento del almacenamiento.

Task 18: Comprobación rápida del plan de energía en Windows (Windows)

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

Qué significa: Estás en Balanced. En algunos sistemas eso está bien. En otros es una limitación silenciosa.

Decisión: Cámbiate a un plan de alto rendimiento para benchmarking; si arregla los FPS, has encontrado un problema de política, no del kernel.

Broma #2: El software de control RGB tiene la singular habilidad de reducir FPS mientras aumenta “frames por segundo” en tus ventiladores.

Tres micro-historias corporativas desde la trinchera

Micro-historia 1: El incidente causado por una suposición errónea

Un estudio tenía una suite interna de benchmarks para un shooter competitivo. La suite corría cada noche en varios escritorios idénticos: dual-boot Windows y Linux, mismas configuraciones de BIOS (o eso pensaban), misma rama de driver GPU (o eso pensaban), misma build del juego.

Un mes, los números de Linux comenzaron a bajar—despacio. No un acantilado catastrófico, solo una erosión constante en los lowest 1%. Los ingenieros de build asumieron “los drivers de Linux son inestables” y comenzaron a abrir bugs contra el equipo de render. El equipo de render hizo lo que hacen los equipos de render cuando están acorralados: añadieron instrumentación. Mostró stalls periódicos correlacionados con streaming de assets y escrituras de caché de sombreado.

Después de demasiado tiempo, alguien finalmente miró los logs del sistema. Un técnico de operaciones, con buena intención, había habilitado un scrub semanal del sistema de archivos y una ventana de pruebas SMART largas en la partición Linux. La ejecución coincidía con las pruebas. Windows no tenía el mismo calendario de mantenimiento. La CPU estaba bien; la latencia de almacenamiento no lo estaba.

La solución fue dolorosamente poco glamorosa: mover trabajos de mantenimiento fuera del horario de benchmarks, fijar la caché de sombreado en NVMe local rápido y aplicar un “modo benchmark” mediante un runbook. El rendimiento en Linux volvió. El equipo de render recuperó su semana. Ops recibió el recordatorio de que “idéntico” no es idéntico cuando existe cron.

Micro-historia 2: La optimización que salió mal

Un grupo de TI empresarial quiso hacer estaciones Linux “más ágiles” para un laboratorio de demos. Alguien leyó que activar escalado de frecuencia agresivo ahorra energía sin “impacto en el usuario”. Desplegaron una configuración que movía la EPP hacia ahorro y habilitaba estados de idle más profundos. Sus dashboards se veían geniales: menos consumo en reposo, menos temperaturas, orgullosos de instalaciones.

Llegó la semana de demos. El laboratorio ejecutó un título VR brutalmente sensible al tiempo por frame. El FPS promedio no era terrible, pero la experiencia del headset tenía hiccups periódicos—exactamente los que provocan náuseas y enfado en la gerencia. El equipo culpó al runtime VR, luego al driver GPU, luego al SO. Todos estaban equivocados.

El profiling mostró latencia de rampa de frecuencia: la CPU no hacía boost lo suficientemente rápido cuando el hilo principal del juego lo demandaba. El sistema era “eficientemente” tarde. Revirtieron a una política orientada al rendimiento durante las sesiones de demo y mantuvieron el perfil de ahorro energético para reposo.

La lección no fue “nunca ahorrar energía”. La lección fue: la política de energía es un contrato de carga de trabajo. Si tu carga requiere baja latencia, deja de fingir que es una hoja de cálculo.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa ejecutaba un cliente multiplataforma usado en entrenamiento de simulación. El cliente era gráficamente pesado, pero el problema real era consistencia: los instructores necesitaban experiencias idénticas en kioscos Windows y Linux. Pequeño jitter causaba divergencia visible en escenarios sincronizados.

Hicieron algo radicalmente poco cool: escribieron un runbook y lo aplicaron. Mismo driver GPU, mismo calendario de parches OS, mismos ajustes de compositor, mismo plan de energía, misma lista de servicios en segundo plano. Los benchmarks corrían desde arranque limpio con red apagada, los logs se capturaban en un share central y cada cambio requería una comparación antes/después con percentiles de tiempo por frame.

Cuando una actualización de proveedor degradó el pacing en Linux, lo detectaron en un día porque las métricas eran estables y el entorno estaba controlado. Revertir el driver fue trivial. No necesitaron heroísmos ni discutir sensaciones. Los gráficos fueron groseros y claros.

La verdad aburrida: la mayoría de “misterios de rendimiento de SO” desaparecen cuando tratas tu rig de juegos como un sistema de producción y dejas de permitir que daemons aleatorios improvisen en escena.

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

1) “Linux tiene menos FPS en general”

Síntoma: FPS promedio bajan 10–30% vs Windows, de forma consistente.

Causa raíz: governor/EPP de CPU configurado para ahorro, turbo deshabilitado o límites OEM del portátil activos en Linux.

Solución: Poner governor en performance para pruebas; verificar boost; revisar térmicas y límites de potencia; asegurar que el driver correcto de CPU (intel_pstate/amd_pstate) esté activo.

2) “Los FPS están bien pero hay stutter cada pocos segundos”

Síntoma: FPS promedio plano, ugly 1% lows, picos periódicos en tiempo por frame.

Causa raíz: E/S en background (caché de sombreado, indexado, servicios de actualización), reclaim de memoria, actividad de swap o tareas programadas de mantenimiento.

Solución: Monitoriza iostat/vmstat; detén jobs en segundo plano; mueve juego/caché de sombreado a SSD rápido; añade RAM si haces paging; mantén espacio libre saludable.

3) “Sin bordes es peor que pantalla completa” (o al revés)

Síntoma: Cambios de modo alteran FPS/latencia drásticamente entre SOs.

Causa raíz: Diferentes rutas de present/compositor: comportamiento de DWM y optimizaciones en Windows; políticas de compositor en Linux (Wayland/X11), gating de VRR, buffering extra.

Solución: Prueba pantalla completa exclusiva, sin bordes y ventana en cada SO. En Linux, prueba X11 vs Wayland. Escoge el modo que dé pacing estable, no solo FPS pico.

4) “Linux se siente lento con vsync, pero Windows no”

Síntoma: La latencia de entrada aumenta más de lo esperado con vsync activado.

Causa raíz: Diferentes valores por defecto de buffering (doble vs triple buffer), vsync impuesto por el compositor o diferencias en la profundidad de cola en la pila del driver.

Solución: Ajusta vsync en el juego, el limitador y modos de baja latencia. Considera VRR. Evita apilar limitadores (juego + driver + compositor).

5) “Después de actualizar el driver, los FPS cambiaron”

Síntoma: Cambio súbito de rendimiento tras actualizar driver GPU o kernel.

Causa raíz: Invalidación de caché de sombreado, nuevo comportamiento de scheduling, flags por defecto distintos o regresiones.

Solución: Reconstruye caches (el stutter del primer arranque es real), compara versiones de driver, mantén un camino de rollback conocido y registra baselines de benchmark.

6) “La actividad de red mata los FPS”

Síntoma: Descargas/streaming provocan dips de frame.

Causa raíz: Tormentas de interrupciones y tiempo de CPU en la pila de red; mala distribución de IRQ; drivers defectuosos.

Solución: Verifica distribución de IRQ; asegura drivers/firmware NIC modernos; prueba con red desconectada para confirmar; considera balanceo de IRQ y afinidad de CPU solo tras medir.

7) “Peor en CPUs híbridas”

Síntoma: Jitter o FPS inconsistente en CPUs con núcleos de rendimiento/eficiencia.

Causa raíz: Problemas de colocación de hilos, migración entre tipos de núcleo o desajuste de política de energía.

Solución: Actualiza OS/kernel; asegura soporte correcto del scheduler; en Windows, revisa Game Mode; en Linux, considera kernels más nuevos y verifica comportamiento de CPUfreq/CPPC.

Listas de verificación / plan paso a paso

Checklist A: Hacer el benchmark justo (haz esto antes de discutir en línea)

1. Usa la misma versión del juego, misma escena/mapa, mismas opciones, misma resolución, mismos ajustes de upscaler.
2. Precalienta caches: ejecuta la escena una vez, luego mide la segunda ejecución (o registra ambas: cold vs warm).
3. Arregla la política de energía:
   • Windows: establece un plan de alto rendimiento para pruebas.
   • Linux: configura governor/EPP en performance para pruebas.
4. Elimina overlays/recordadores y utilidades “útiles” del proveedor durante la prueba.
5. Desactiva mantenimiento en segundo plano: actualizaciones, indexado, tareas programadas, scrubs.
6. Captura métricas de tiempo por frame, no solo FPS promedio.

Checklist B: Si Linux tiene menos FPS, en orden

1. Verifica que estés usando la GPU discreta y el driver correcto (glxinfo -B, vulkaninfo).
2. Verifica boost de CPU y governor/EPP.
3. Revisa térmicas bajo carga.
4. Comprueba si estás limitado por CPU (usa perf top o gráficos de frametime CPU/GPU en el juego).
5. Si usas Proton: prueba un título Vulkan nativo para aislar la sobrecarga de traducción.
6. Prueba Wayland vs X11, y ajustes del compositor que afecten VRR/vsync.

Checklist C: Si Windows tiene stutter pero Linux es fluido

1. Revisa el plan de energía de Windows y utilidades del proveedor que limiten CPU/GPU.
2. Revisa características a nivel de driver que alteren la planificación (p. ej., aceleración por hardware, modos de baja latencia).
3. Revisa servicios en segundo plano: mecanismos de actualización, telemetría, indexado.
4. Revisa almacenamiento: ¿algo está escaneando o descargando mientras juegas?
5. Valida con arranque limpio y elementos mínimos de inicio para aislar.

Checklist D: Cuando sospechas E/S y caché de sombreado

1. Confirma que el juego y la caché de sombreado estén en SSD local rápido.
2. Observa iostat -xz y vmstat durante el stutter.
3. Asegura espacio libre suficiente; los SSD se comportan raro cuando están llenos.
4. Espera que la compilación de sombreadores en la primera ejecución cause stutter. Mide la segunda ejecución.

Preguntas frecuentes

1) Si la CPU es la misma, ¿no deberían ser iguales los FPS?

No. La CPU es un componente; el SO decide planificación, estados de energía, comportamiento de temporizadores, enrutamiento de interrupciones e interacciones con la pila de controladores. Eso cambia el comportamiento efectivo de la CPU.

2) ¿Por qué las medias coinciden pero los lowest 1% difieren?

Porque los picos vienen de contendencia y stalls: E/S en segundo plano, reclaim de memoria, interrupciones, compilación de sombreadores y sincronización del compositor. La media esconde el dolor.

3) ¿Linux siempre es más lento para jugar?

No. Títulos Vulkan nativos pueden funcionar extremadamente bien. Pero las capas de traducción (DXVK/vkd3d), comportamiento del compositor y diferencias de drivers pueden inclinar los resultados en cualquiera de las direcciones.

4) ¿El governor de rendimiento siempre ayuda en Linux?

Suele ayudar la consistencia del tiempo por frame al reducir la latencia de rampa de frecuencia. Pero puede aumentar calor y disparar throttling térmico, lo que puede anular las ganancias. Mide bajo carga sostenida.

5) ¿Más RAM reduce el stutter?

Si estás haciendo paging o forzando reclaim agresivo, sí—drásticamente. Si ya tienes margen, más RAM no solucionará la sobrecarga del driver o la latencia inducida por el compositor.

6) ¿Por qué cambiar de Wayland a X11 cambia FPS?

Rutas de composición y presentación diferentes. Soporte VRR, enforcement de vsync y gestión de buffers difieren por compositor y driver, y esas diferencias se muestran como cambios en latencia y pacing.

7) ¿Las mitigaciones de seguridad de CPU son un factor real en FPS?

A veces. Pueden aumentar los costos de syscall y cambio de contexto y afectar el comportamiento de barreras de memoria. El efecto varía por CPU, kernel y carga. No lo discutas—mídelo.

8) ¿El almacenamiento realmente se relaciona con los FPS?

Para el FPS promedio, por lo general no. Para picos en el tiempo por frame, absolutamente—especialmente en juegos con streaming intensivo y durante actividad de caché de sombreado. Si ves I/O wait durante caídas, el almacenamiento está en la cadena.

9) ¿Debería fijar mi juego a núcleos específicos?

Sólo después de probar que hay un problema de planificación/interrupciones. Fijar afinidad puede ayudar o puede empeorar al atrapar el juego en un núcleo con muchas interrupciones o al privar hilos worker.

10) ¿Por qué Proton a veces supera a Windows?

Puede pasar cuando la ruta Vulkan es más eficiente que la ruta DirectX nativa en Windows, o cuando la planificación del driver difiere favorablemente. Es específico de la carga, no una ley de la naturaleza.

Siguientes pasos que realmente mueven la aguja

Si quieres resultados accionables en lugar de debates interminables “Windows vs Linux”, haz esto:

1. Mide tiempos por frame, no solo FPS. Sigue promedios y percentiles. Los picos son el enemigo.
2. Bloquea la política de energía para las pruebas. Modo rendimiento primero, luego ajusta hacia abajo con intención.
3. Demuestra si estás limitado por CPU, GPU o stalls de E/S. Usa perf, gráficos de utilización y iostat/vmstat.
4. Controla el entorno. Mismos drivers, mismo modo de compositor, mismos servicios en segundo plano. Trátalo como una ventana de cambio en producción.
5. Cambia solo una cosa a la vez. Si cambias OS, driver, kernel, governor, compositor y ajustes del juego a la vez, no probaste—echaste los dados.

Windows y Linux no son solo pieles sobre la misma CPU. Son filosofías operativas distintas con valores predeterminados distintos. La diferencia de FPS es la factura que pagas por esos valores. La buena noticia: la mayor parte de la factura está detallada, y puedes disputar los cargos—si llegas con mediciones.