Cómo perdió 3dfx: la caída más triste de un rey

La era del hacedor de reyes: por qué importó 3dfx

3dfx irrumpió en el mercado de PC de los 90 como una caché de página limpia: de repente todo se sentía más rápido y no había vuelta atrás. Antes de los aceleradores 3D para consumidores, las “gráficas 3D” en PC eran una pila inestable de rasterizadores por software, modelos de controladores raros y compromisos que siempre terminaban en lo mismo: “Parece sopa, funciona como arrepentimiento”.

Entonces llegó Voodoo Graphics. No solo añadió frames por segundo. Definió qué se consideraba “bueno”: texturas filtradas, movimiento suave, un objetivo estable para desarrolladores. Si hacías juegos, querías lo que compraban los jugadores. Si comprabas una GPU, querías aquello para lo que se construían los juegos. Es economía de volante, pero impulsada por triángulos.

Pero aquí está la trampa: los volantes son dispositivos operacionales. Necesitan entrada constante. No puedes saltarte las partes aburridas. No puedes llegar tarde. No puedes alienar tu canal de distribución. No puedes apostar tu ecosistema a una API privada para siempre y llamarlo estrategia.

3dfx fue rey porque entregaba una experiencia fiable antes de que “fiabilidad” fuera una disciplina formal en hardware de consumo para PC. Y 3dfx cayó porque dejaron de gestionar todo el negocio como un sistema de producción.

Hechos y contexto que deberías recordar

Estos son puntos concretos que te ayudan a razonar sobre la caída sin convertirla en mito.

1. Voodoo Graphics (1996) era una tarjeta añadida solo para 3D — mantenías una tarjeta 2D y usabas un cable pass-through para 3D. Era engorroso, pero funcionaba.
2. Glide fue una API propietaria diseñada para acercarse al hardware. A los desarrolladores les encantaba por el rendimiento y la predictibilidad; el mercado luego castigó el vendor lock-in.
3. Direct3D maduró rápido a finales de los 90. A medida que Microsoft iteró, la promesa de “escribe una vez para jugar en Windows” se hizo lo bastante real como para dañar a Glide.
4. 3dfx adquirió STB Systems (1998) — un fabricante de placas — moviéndose hacia la integración vertical y cambiando las relaciones con los socios de tarjetas.
5. NVIDIA iteró sin descanso, pasando de RIVA 128 a TNT a GeForce con una cadencia agresiva y fuerte ejecución con OEM.
6. Voodoo2 popularizó SLI (scan-line interleave), permitiendo a dos tarjetas compartir trabajo de renderizado. Fue ingenioso y caro—y no fue ganador en la curva de costes a largo plazo.
7. Voodoo3 integró 2D y 3D, eliminando el desorden del pass-through. Fue un paso necesario, pero la barra competitiva subía.
8. La calidad de los controladores se volvió un diferenciador. Estabilidad, compatibilidad con juegos y liberaciones frecuentes empezaron a importar tanto como los picos de benchmark.
9. La ejecución de la hoja de ruta de 3dfx se resbaló más adelante mientras los competidores alineaban lanzamientos de silicio con ciclos de refresco OEM—el tiempo es una característica.

Un chiste corto, porque la historia merece un respiro: el problema de 3dfx no era solo faltar a una fecha de lanzamiento—era tratar las fechas de lanzamiento como dependencias opcionales.

Guía rápida de diagnóstico: encuentra el cuello de botella

Si quitas la nostalgia, 3dfx perdió porque no pudieron mantener estable la tubería de extremo a extremo: desde la adopción por parte de desarrolladores hasta el espacio en estantería de los OEM, la fabricación, los controladores y el silicio de siguiente generación. Aquí tienes una guía que puedes reutilizar para cualquier situación de “tenemos la mejor tecnología, ¿por qué estamos perdiendo?”.

Primero: ¿el ecosistema te está eligiendo a ti?

• Revisa la superficie para desarrolladores: ¿eres el objetivo por defecto de la API/SDK? Si no, pagas un impuesto que tus competidores evitan.
• Revisa la matriz de compatibilidad: ¿cuántos errores de “funciona bien en X” están abiertos? Si la respuesta necesita una hoja de cálculo con emociones, ya vas retrasado.
• Revisa la cadencia de actualizaciones: ¿estás enviando correcciones semanal/mensualmente, o caídas trimestrales de controladores con rezos?

Segundo: ¿el canal trabaja contigo o a tu alrededor?

• Revisa los design wins con OEM: Si los grandes fabricantes no te incluyen por defecto, tu volumen es frágil, tus márgenes son fantasías y tu marca está haciendo trabajo no remunerado.
• Revisa los incentivos de los socios: Si acabas de cambiar las reglas para tus socios de placas, asume que financiarán la hoja de ruta del competidor por despecho o supervivencia.
• Revisa la previsibilidad de suministro: ¿puedes entregar unidades cuando el mercado compra? Fallar un ciclo de regreso a clase o de vacaciones y lo sentirás años.

Tercero: ¿estás ejecutando las partes aburridas?

• Revisa el rendimiento de fabricación y QA: Un chip brillante que se envía tarde es un rumor, no un producto.
• Revisa el riesgo de la hoja de ruta: ¿estás acumulando varios grandes cambios a la vez (nuevo proceso, nueva arquitectura, nueva estrategia de placas)? Así fabricas retrasos.
• Revisa la pista financiera: Si tu posición de efectivo depende del “flagship del próximo trimestre”, no estás haciendo ingeniería—estás jugando a la ruleta.

Cómo perdió 3dfx: cinco modos de fallo

1) Apostar por Glide: rendimiento hoy, deuda de adopción mañana

Glide tenía sentido al principio. Era rápido, relativamente limpio y ofrecía a los desarrolladores un objetivo estable mientras la pila 3D de Windows era inmadura. En términos de operaciones, Glide fue el protocolo RPC interno que permitió al equipo entregar funciones sin esperar a un comité de estándares. Buena jugada—hasta que dejó de serlo.

A medida que Direct3D mejoró y OpenGL siguió siendo relevante para ciertas cargas, el mundo cambió. Los desarrolladores no quieren tres rutas de renderizado a menos que una de ellas les compre un mercado significativo. Una vez que los competidores ofrecieron rendimiento “lo suficientemente bueno” en APIs estándar, Glide se convirtió en una carga de mantenimiento. 3dfx cargaba costos de integración a medida mientras los rivales obtenían el ecosistema gratis.

Esto no es “lo malo es ser propietario”. Lo propietario está bien cuando te compra tiempo y gastas ese tiempo comprando la siguiente ventaja. Lo propietario es fatal cuando se convierte en tu identidad, porque las identidades no se refactorizan.

2) Integración vertical vía STB: poseer la placa, perder el canal

Adquirir STB es el tipo de movimiento que luce racional en una hoja de cálculo: controlar la fabricación, capturar margen, asegurar calidad, coordinar lanzamientos. En realidad es una transacción de confianza con tus socios, y la confianza es una dependencia de producción.

Antes de STB, 3dfx vendía chips. Los socios de placas manejaban el negocio sucio de construir tarjetas, distribuirlas, empaquetarlas y moverlas por retail y acuerdos OEM. Tras la adquisición, esos socios tuvieron que preguntarse: “¿Estamos ayudando a un proveedor o financiando a un competidor?” Muchos optaron por reducir su exposición.

El daño al canal es lento al principio, luego repentino. Se ve como “suavidad extraña en la demanda”, luego “presencia inesperada y fuerte del competidor”, luego “¿por qué todos los design wins de OEM van a otro lado?” No es un misterio; es una consecuencia.

3) Ejecución y timing: la característica que no puedes medir en un benchmark

En el mundo GPU, enviar producto cuando el mercado compra es una ventaja brutal. Ciclos de refresco OEM, ventas de regreso a clases, builds festivos—son ventanas temporales. Si las fallas, no solo pierdes ingresos; pierdes presencia mental y espacio en estanterías. Tu competidor se convierte en el por defecto.

3dfx tenía ingeniería fuerte, pero la industria entró en una guerra de cadencias. NVIDIA convirtió “nuevo silicio frecuentemente” en hábito y luego en promesa de marca. Eso cambia las expectativas del cliente. De repente, una empresa que envía más despacio no parece “cuidadosa”; parece antigua.

4) Controladores y compatibilidad: la fiabilidad es un producto

Los jugadores experimentan los controladores como “la tarjeta”. El cliente medio no separa silicio de software. Si tu GPU insignia falla en tres juegos principales y la del competidor no, el competidor es “más rápido”, aunque el benchmark diga lo contrario.

A medida que los juegos se diversificaron y las APIs convergieron, la corrección del controlador y las correcciones rápidas se volvieron un foso competitivo. Esa es lógica SRE: el servicio más rápido es el que no te despierta a las 2 a.m. El mercado GPU aprendió la misma lección con vocabulario distinto.

5) Estrategia competitiva: NVIDIA jugó en todo el tablero

NVIDIA no solo construía GPUs; construyó un modelo operativo. Entendieron relaciones OEM, herramientas para desarrolladores y trenes de lanzamiento. Optimizaban para la iteración y la alineación de plataforma. 3dfx optimizaba por tener razón.

Tener razón está bien. Ser enviable es mejor.

Segundo chiste corto (y el último, porque las reglas son reglas): En hardware, “lo arreglaremos en software después” es como “lo arreglaremos en DNS”—es técnicamente posible y emocionalmente costoso.

El espejo de ops: lo que 3dfx enseña a los SRE y a ingenieros de almacenamiento

Puedes tratar esta historia como un drama tecnológico retro. O puedes tratarla como un postmortem para el trabajo de sistemas moderno. Recomiendo lo segundo, porque paga el alquiler.

La cita de fiabilidad que deberías tener en la pared

Idea parafraseada de Gene Kranz: “Sé duro y competente”. En términos de ops: no entres en pánico y no improvises.

Lección A: tu “estrategia de API” es solo otra forma de gestión de dependencias

Glide era una dependencia. Era poderosa, pero requería mantenimiento, evangelización y prueba constante de que valía la complejidad. A medida que Direct3D se volvió viable, Glide necesitaba (a) ser degradada con gracia, (b) convertirse en un detalle de implementación detrás de estándares, o (c) hacerse tan atractiva que se convirtiera en el estándar. 3dfx no aterrizó ninguna de esas condiciones finales.

Traduce eso a ops: si construyes herramientas internas, las posees. Si construyes orquestación personalizada, la posees. Si construyes tu propia capa de almacenamiento, la posees. Poseer está bien—hasta que no puedes dotarla de personal y tus competidores adoptan el estándar aburrido y envían más rápido.

Lección B: la integración vertical expande el radio de explosión

Comprar STB no fue “solo” una elección de fabricación. Cambió contratos, incentivos de socios y los modos de fallo de la empresa. Es similar a decidir ejecutar tu propio centro de datos, tu propia distribución de Kubernetes y tu propio firmware de SSD personalizado. Puedes hacerlo. Pero ahora cada outage es tu outage, cada retraso es tu retraso y cada socio se vuelve sospechoso de tus intenciones.

Lección C: el timing y la cadencia vencen a la excelencia de una sola entrega

La cadencia de NVIDIA forzó al mercado a esperar mejoras frecuentes. En operaciones, la cadencia es tu tren de lanzamientos y tu bucle de respuesta a incidentes. Si envías correcciones raramente, enseñas a los clientes a aceptar dolor. Luego aparece un competidor y les enseña a esperar confort. Tu tasa de churn se vuelve física.

Lección D: “mejor rendimiento” es irrelevante sin “mejor experiencia”

Los benchmarks son pruebas de laboratorio. El mundo real tiene cargas desordenadas, casos límite raros y manejo de fallos poco glamuroso. Por eso existe SRE. La lección de 3dfx es que los clientes compran resultados, no gráficos máximos.

Tres micro-historias corporativas desde el frente

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

Una compañía mediana ejecutaba una canalización acelerada por GPU para renderizado e inferencia ML. Tenían dos proveedores en juego y el equipo supuso que “CUDA vs no-CUDA” era el único diferenciador que importaba. La suposición: una vez que el SDK del proveedor funciona, el hardware es fungible.

Firmaron un acuerdo de suministro basado en benchmarks de rendimiento pico de una única prueba limpia. Luego desplegaron las nuevas tarjetas en un clúster donde los trabajos eran explosivos y los patrones de asignación de memoria caóticos. En días, la latencia de cola aumentó y el scheduler de jobs empezó a entrar en thrash. El equipo culpó a Kubernetes, luego al kernel, luego al “ruido aleatorio”.

El problema real fue el comportamiento del controlador bajo presión de memoria combinado con una interacción sutil en su runtime de contenedores. El controlador del nuevo proveedor se recuperaba de fallos transitorios de asignación de forma distinta. No era “peor” en un benchmark; era peor en su realidad de producción.

Arreglarlo requirió fijar versiones de drivers, alterar reglas de empaquetado de jobs y crear una pool canaria con una matriz de compatibilidad estricta. Lo importante: dejaron de asumir que una GPU es una GPU. Los ecosistemas son productos, no accesorios.

Micro-historia 2: La optimización que se volvió en contra

Una empresa de ecommerce decidió “optimizar” su almacenamiento de artefactos deduplicando agresivamente y pasando a un diseño de sistema de archivos comprimido. El objetivo era noble: reducir gasto en almacenamiento y acelerar descargas cachando más artefactos en menos nodos NVMe.

Desplegaron el cambio rápido, usando un índice inteligente basado en hash mantenido en memoria y periodicamente volcado a disco. Las pruebas de carga se veían bien. En producción, los picos nocturnos de CI causaron una tormenta: las compactaciones se solaparon con el tráfico de lectura pico, saturando I/O y aumentando tiempos de build. Los desarrolladores notaron primero, luego los ejecutivos. Todos hicieron las cuentas, y las cuentas fueron feas.

El contragolpe no fue la idea de compresión o dedupe. Fue hacerlo sin aislamiento estricto de I/O y sin modelar el comportamiento de compactación como una carga de trabajo de primera clase. Optimizaron para el caso promedio y pagaron con dolor en la cola.

La corrección fue dolorosamente aburrida: separar nodos de compactación de nodos de servicio de lectura, establecer cgroups de I/O explícitos y limitar la tasa del trabajo de mantenimiento. También aprendieron a tratar el trabajo en segundo plano como trabajo de producción con un SLO.

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

Un equipo de servicios financieros ejecutaba una flota de nodos de procesamiento de datos con SSDs locales y un store de objetos replicado. Nada sofisticado. La práctica aburrida: ensayos semanales de recuperación ante desastres donde realmente fallaban un nodo, restauraban desde backup y validaban checksums de extremo a extremo.

Un día, un bug de firmware provocó que un subconjunto de SSDs empezara a lanzar errores no corregibles bajo un patrón de escritura específico. No todos a la vez—lo suficiente para corromper algunos objetos silenciosamente antes de que las capas superiores lo notaran.

Porque el equipo había practicado, no debatieron qué hacer. Pusieron en cuarentena los nodos afectados, limpiaron réplicas, restauraron copias limpias y rotaron firmware en los dispositivos restantes. El incidente dolió, pero no se convirtió en titular.

La lección es ofensiva en su simplicidad: ensaya. La fiabilidad no es un documento; es un hábito.

Tareas prácticas: comandos, salidas y decisiones

La caída de 3dfx es una historia de estrategia, pero la estrategia falla por mecánica: ciclos perdidos, controladores inestables, tropiezos de suministro y rendimiento opaco. Las tareas abajo son las mecánicas que deberías ejecutar en tu mundo—porque tu competidor ya lo hace.

Tarea 1: Identificar la GPU y la versión del driver (verdad base)

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:14:21 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15    Driver Version: 550.54.15    CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------|
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|  0  A10               On      | 00000000:65:00.0 Off |                  Off |
| 30%   52C    P2    118W / 150W|  18342MiB / 23028MiB |     92%      Default |
+-------------------------------+----------------------+----------------------|

Qué significa: Ahora conoces la versión exacta del driver y si estás cerca de límites de potencia/memoria.

Decisión: Si los incidentes se correlacionan con cambios de driver, congela esta versión y prueba actualizaciones primero en una pool canaria.

Tarea 2: Revisar ancho/velocidad del enlace PCIe (el asesino silencioso del throughput)

cr0x@server:~$ sudo lspci -vv -s 65:00.0 | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Qué significa: La tarjeta es capaz de PCIe Gen4 x16, pero está corriendo a Gen3 x8.

Decisión: Investiga ajustes del BIOS, risers, cableado de ranura o throttling térmico. “A veces hace buen benchmark” es como esto se esconde.

Tarea 3: Confirmar que el driver del kernel está cargado y saludable

cr0x@server:~$ lsmod | grep -E "^nvidia|^amdgpu"
nvidia_drm             86016  2
nvidia_modeset       1318912  3 nvidia_drm
nvidia_uvm           3649536  0
nvidia              62713856  86 nvidia_uvm,nvidia_modeset

Qué significa: Los módulos esperados están cargados; si faltan, no estás usando la GPU que crees.

Decisión: Si un módulo hace flapping tras actualizaciones, fija la combinación kernel/driver y programa rollouts controlados.

Tarea 4: Leer logs del kernel por resets de GPU o errores PCIe

cr0x@server:~$ sudo journalctl -k -b | grep -iE "nvrm|amdgpu|pcie|aer" | tail -n 8
Jan 13 09:58:02 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Jan 13 09:58:02 server kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 13 10:02:11 server kernel: NVRM: Xid (PCI:0000:65:00): 31, pid=18722, GPU has fallen off the bus.

Qué significa: “GPU has fallen off the bus” no es un bug de la aplicación. Es estabilidad: potencia, térmicos, firmware o integridad PCIe.

Decisión: Escala a hardware/firmware; reduce power cap; verifica cables/risers; pon en cuarentena el nodo.

Tarea 5: Comprobar margen térmico (los precipicios de rendimiento son reales)

cr0x@server:~$ nvidia-smi -q -d TEMPERATURE,POWER | sed -n '1,120p'
==============NVSMI LOG==============
Temperature
    GPU Current Temp                  : 83 C
    GPU Shutdown Temp                 : 95 C
    GPU Slowdown Temp                 : 87 C
Power Readings
    Power Draw                        : 149.21 W
    Power Limit                       : 150.00 W
    Default Power Limit               : 150.00 W

Qué significa: Estás cerca de la temperatura de ralentización y del límite de potencia; los clocks pueden ya estar constreñidos.

Decisión: Mejora la refrigeración, sube curva de ventilador, reduce ambiente o limita potencia para estabilidad. Rendimiento consistente vence números heroicos espigados.

Tarea 6: Identificar saturación CPU vs saturación GPU

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0-40-generic (server) 	01/13/2026 	_x86_64_	(64 CPU)

10:14:25 AM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
10:14:26 AM  all  82.10   0.00   6.45    0.12  0.00   0.55    0.00  10.78
10:14:26 AM   0  98.00   0.00   1.00    0.00  0.00   0.00    0.00   1.00
10:14:26 AM   1  97.00   0.00   2.00    0.00  0.00   0.00    0.00   1.00

Qué significa: La CPU está muy ocupada; si la utilización de GPU es baja, el cuello de botella probablemente está en preprocesado por CPU o en un estrangulamiento de un solo hilo.

Decisión: Perfila la canalización, aumenta paralelismo o mueve etapas de CPU fuera del camino crítico.

Tarea 7: Revisar latencia de almacenamiento (porque “GPU lenta” suele ser “disco lento”)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-40-generic (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          52.12    0.00    6.31    8.44    0.00   33.13

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         820.0  65536.0     0.0   0.00   12.40    79.92   410.0  32768.0     0.0   0.00   18.72    79.92   13.22  98.00

Qué significa: NVMe está cerca del 98% de utilización y los await están en dos dígitos. Esa es latencia que siente tu canalización.

Decisión: Añade dispositivos, separa cargas de lectura/escritura, ajusta queue depth o cachea entradas. No “optimices código GPU” mientras el almacenamiento grita.

Tarea 8: Encontrar los principales consumidores de I/O rápidamente

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 58.12 M/s | Total DISK WRITE: 41.33 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
18722 be/4  build    45.21 M/s   12.03 M/s   0.00 %  72.10 %  python3 preprocess.py
19211 be/4  build     4.12 M/s   21.88 M/s   0.00 %  38.44 %  zstd -T0 artifacts.tar

Qué significa: Tu “job GPU” incluye preprocesado por CPU y compresión que puede dominar I/O.

Decisión: Mueve la compresión fuera del nodo, limita su tasa o prográmala fuera de las ventanas pico de inferencia/entrenamiento.

Tarea 9: Validar espacio de sistema de archivos y margen de inodos (el apagón tonto)

cr0x@server:~$ df -h /var /mnt/datasets
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  1.8T  1.7T   62G  97% /
/dev/nvme1n1p1  3.6T  2.1T  1.4T  61% /mnt/datasets

Qué significa: Root está al 97%; estás a un storm de logs de que las aplicaciones fallen de formas creativas.

Decisión: Libera espacio, rota logs o mueve rutas de escritura intensiva fuera de root. Luego configura alertas al 80/90/95% con un humano en on-call.

Tarea 10: Revisar drops/retransmisiones de red (porque las canalizaciones distribuidas mienten)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      9876543210  8123456      0    1245       0       0
    TX:  bytes packets errors dropped carrier collsns
      8765432109  7345678      0       8       0       0

Qué significa: Drops en RX a escala pueden traducirse en lentitud o timeouts “aleatorios” aguas arriba.

Decisión: Inspecciona los buffers de anillo de la NIC, congestión de switch, desajustes de MTU o QoS. No culpes a la aplicación hasta que los paquetes se comporten.

Tarea 11: Confirmar que DNS y descubrimiento de servicios no son el cuello de botella

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions:               124812
Cache hits:                  98110
Cache misses:                26702
DNSSEC verdicts:                 0

Qué significa: Altos misses relativos a hits pueden indicar clientes charla-chata o mal cacheo; retrasos DNS pueden amplificar la latencia cola.

Decisión: Añade cacheo, reduce la frecuencia de lookups o arregla el comportamiento del cliente. “Es solo DNS” sorprendentemente a menudo se convierte en “siempre es DNS”.

Tarea 12: Rastrear presión de memoria a nivel de proceso y riesgo de OOM

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           503Gi       462Gi        11Gi       2.1Gi        30Gi        18Gi
Swap:            0B          0B          0B

Qué significa: Solo 18Gi disponibles en un sistema de 503Gi sugiere que estás a una explosión de reclamaciones o kills por OOM.

Decisión: Establece límites de memoria, reduce jobs concurrentes, añade swap (con cuidado) o escala horizontalmente. Evita el heroico “pon una máquina más grande” sin entender la forma del uso de memoria.

Tarea 13: Revisar señales de throttling y presión del kernel (realidad moderna)

cr0x@server:~$ cat /proc/pressure/io
some avg10=0.58 avg60=1.21 avg300=0.98 total=23812811
full avg10=0.22 avg60=0.48 avg300=0.39 total=9123812

Qué significa: La presión “full” de IO indica periodos donde tareas quedan bloqueadas por I/O. Esto es un impuesto de latencia en todo el sistema.

Decisión: Reduce la contención I/O, aisla cargas o provisiona más ancho de banda. No afines kernels GPU mientras el OS espera almacenamiento.

Tarea 14: Validar que el mantenimiento en background no te está comiendo

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
19211 zstd            612.3  1.2
18722 python3         288.7  3.8
 921  kswapd0          82.4  0.0
 741  nvme_poll_wq     31.0  0.0

Qué significa: Compresión y reclaim están consumiendo CPU masiva. Tu “carga principal” compite con housekeeping.

Decisión: Limita tasa de mantenimiento, usa cgroups o programa trabajos de fondo fuera de pico. Esta es la versión operacional de “integración vertical”: posees las consecuencias.

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

Esta sección es donde la nostalgia muere y se forma la memoria muscular.

1) Síntoma: “Tenemos el hardware más rápido, pero los desarrolladores nos ignoran”

Causa raíz: Tu superficie de plataforma es no estándar, costosa de apuntar o mal proveída de herramientas. Ventajas tipo Glide se vuelven pasivos tipo Glide.

Solución: Soporta bien los estándares dominantes, envía excelentes herramientas y convierte la ruta feliz en la predeterminada. Los caminos propietarios rápidos deben ser opcionales y aditivos.

2) Síntoma: “Enviamos grandes productos pero fallamos trimestres”

Causa raíz: La cadencia de lanzamiento no se gestiona como un sistema: las dependencias se apilan, el riesgo está acoplado y no hay un plan creíble para deslices.

Solución: Divide la hoja de ruta en entregables más pequeños, aplica puertas de fase y alinea lanzamientos con ventanas de mercado. El timing es un requisito, no una preferencia.

3) Síntoma: “Los socios dejaron de impulsar nuestro producto”

Causa raíz: Los incentivos se rompieron. A menudo causado por integración vertical, conflicto de canal o suministro impredecible.

Solución: Restaura la confianza mediante programas claros para socios, precios estables y asignaciones predecibles. Si vas directo, sé honesto e invierte en consecuencia—no lo hagas a medias.

4) Síntoma: “Los benchmarks lucen bien, pero los clientes se quejan de stutter/caídas”

Causa raíz: Deuda en controladores y compatibilidad. La larga cola de juegos/apps te castiga.

Solución: Construye un laboratorio de compatibilidad, prioriza cargas top, envía actualizaciones de controladores frecuentes e instrumenta telemetría de crashes. El trabajo de fiabilidad es trabajo de producto.

5) Síntoma: “Optimizamos costos y nos volvimos más lentos”

Causa raíz: Trabajo de fondo y compactación/mantenimiento chocan con demanda pico. La optimización movió el cuello de botella.

Solución: Aísla el mantenimiento, limita su tasa y mide la latencia en cola. Si no lo puedes graficar, no lo puedes confiar.

6) Síntoma: “Todo iba bien, y de repente somos irrelevantes”

Causa raíz: Cadencia competitiva y cambios de plataforma. Una API estándar madura, los acuerdos OEM se mueven y tu diferenciador se evapora.

Solución: Vigila indicadores líderes: adopción de desarrolladores, design wins, cadencia de controladores, fiabilidad de suministro. No esperes a que los ingresos te digan la verdad.

Listas de verificación / plan paso a paso

Lista 1: Si apuestas por tecnología propietaria (la trampa Glide)

1. Define el plan de sunsetting desde el día uno: cómo degradas con gracia hacia estándares.
2. Mide adopción mensualmente: número de integraciones de primera clase, no “interés”.
3. Presupuesta trabajo de compatibilidad como equipo permanente, no como pánico de lanzamiento.
4. Envía una suite de conformidad para que los socios puedan validar sin rogarte.
5. Haz tu camino propietario opcional: la API estándar debe seguir siendo excelente.

Lista 2: Si consideras integración vertical (la lección STB)

1. Lista socios que pierden margen si integras; asume que reaccionarán.
2. Decide si estás dispuesto a perderlos. Si no, no te integres.
3. Construye un modelo de suministro con escenarios de “trimestre perdido”; planea efectivo en consecuencia.
4. Invierte en throughput de QA y análisis de fallos; si no, solo compraste dolor.
5. Comunica temprano y claramente; la ambigüedad genera sabotaje del canal.

Lista 3: Cadencia operacional para una pila hardware/software competitiva

1. Tren de liberación semanal de drivers/herramientas con canaries y rollback.
2. Seguimiento de matriz de compatibilidad: top 50 cargas deben estar verdes.
3. Dashboards de rendimiento: mediana y p99, no solo FPS/throughput pico.
4. Telemetría de suministro y fabricación: tiempos de entrega, riesgo de yield, riesgo de asignación.
5. Revisiones de incidentes que terminen con un cambio en cómo envías, no solo un PDF.

Paso a paso: triage de una situación “perdemos cuota pese a tener buena tecnología”

1. Mapea la tubería: desarrollador → SDK/API → controlador → hardware → placa/OEM → retail/envío. Marca los handoffs.
2. Elige tres indicadores líderes: objetivos de desarrollador, design wins OEM, tasa de crashes de controladores.
3. Realiza una auditoría de cadencia: ¿con qué frecuencia envías correcciones? ¿con qué frecuencia lo hace tu competidor?
4. Encuentra el punto de estrangulamiento: usualmente no es el silicio. Es compatibilidad, suministro o confianza del canal.
5. Arregla una capa a la vez: acoplar arreglos en un “big bang” es cómo recreas la pila de riesgo en etapa tardía de 3dfx.

Preguntas frecuentes

¿Perdió 3dfx porque NVIDIA tenía “mejor tecnología”?

No puramente. NVIDIA ejecutó una cadencia más rápida, mejor alineación con OEM y una estrategia de ecosistema más amplia. La tecnología importó, pero el modelo operativo importó más.

¿Fue Glide un error?

Al principio, no. Fue un atajo pragmático que entregó una gran experiencia cuando los estándares eran inmaduros. El error fue tratarlo como un foso permanente en lugar de una ventaja temporal.

¿Por qué la adquisición de STB dañó tanto?

Cambió los incentivos. Los socios de placas que antes amplificaban a 3dfx ahora tenían que competir con ellos. En hardware, la confianza del canal es un componente de la cadena de suministro.

¿Qué papel jugó Direct3D en la caída?

A medida que Direct3D maduró, redujo el valor de una API propietaria. Los desarrolladores podían apuntar a un estándar y aun así alcanzar a la mayoría de clientes con rendimiento aceptable.

¿Realmente importaban tanto los controladores a finales de los 90?

Sí, y cada vez más. A medida que los juegos se diversificaban y las pilas OS evolucionaban, la compatibilidad y la estabilidad se convirtieron en la experiencia diaria del usuario. La fiabilidad se volvió una característica del producto.

¿Cuál es la lección SRE en que una compañía de GPU de consumo falle?

La fiabilidad de extremo a extremo gana mercados. Un componente rápido dentro de un sistema no fiable no crea un producto fiable. Trata distribución, herramientas y soporte como dependencias de producción de primera clase.

¿Podría 3dfx haber sobrevivido quedándose solo en chips y no haciendo placas?

Posiblemente. Mantenerse solo como proveedor de chips habría reducido el conflicto de canal y permitido a los socios de placas seguir impulsando el producto. No habría resuelto todo, pero elimina una herida autoinfligida importante.

¿La integración vertical siempre es mala?

No. Es poderosa cuando puedes ejecutar fabricación, QA y distribución a escala. Es mala cuando se usa para “arreglar” un problema de canal en lugar de abordar incentivos y cadencia.

¿Cuál es el equivalente moderno de la trampa Glide?

Una capa de plataforma propietaria que los desarrolladores deben adoptar para obtener “rendimiento completo”, mientras que las rutas basadas en estándares quedan rezagadas. Funciona hasta que un competidor hace que la ruta estándar sea lo suficientemente buena y más fácil.

Conclusión: pasos prácticos siguientes

3dfx es la historia de advertencia para cada equipo que cree que la excelencia técnica se convierte automáticamente en poder de mercado. No es así. Ni en GPUs, ni en sistemas distribuidos, ni en almacenamiento, ni en plataformas.

Si quieres evitar la misma clase de caída—ya envíes silicio, software o “solo” una plataforma interna—haz tres cosas este trimestre:

1. Mide la salud del ecosistema: adopción, compatibilidad y cadencia. Si no puedes cuantificarlo, gestionas sensaciones.
2. Audita tu canal e incentivos: socios, clientes internos y equipos adyacentes. Si alguien pierde cuando tú ganas, eventualmente te hará perder.
3. Haz de la fiabilidad un criterio de lanzamiento: estabilidad de controladores, seguridad de actualizaciones, capacidad de rollback y suministro/throughput predecible. Velocidad sin estabilidad es solo una forma más rápida de estrellarse.

Lo más triste de 3dfx no es que perdieran. Muchas empresas pierden. Lo triste es que perdieron teniendo la clase de ventaja temprana por la que la mayoría de equipos matarían—y luego la desangraron por modos de fallo operativos evitables.