Comment 3dfx a perdu : la chute la plus triste d’un roi

L’ère du faiseur de rois : pourquoi 3dfx comptait

3dfx a frappé le marché PC des années 1990 comme un cache de pages vidangé : soudain tout semblait plus rapide, et on ne revenait pas en arrière. Avant les accélérateurs 3D grand public, les « graphiques 3D » sur PC étaient une pile branlante de rasterizers logiciels, de modèles de pilotes étranges et de compromis qui donnaient toujours le même résultat : « Ça ressemble à de la soupe, ça tourne comme du regret. »

Puis Voodoo Graphics est arrivé. Ce n’était pas seulement des images par seconde en plus. C’était la définition du « bon » : textures filtrées, mouvement fluide, cible développeur stable. Si vous faisiez des jeux, vous vouliez la plateforme que les joueurs achetaient. Si vous achetiez un GPU, vous vouliez celui pour lequel les jeux étaient conçus. C’est de l’économie de flywheel, sauf que l’énergie est fournie par des triangles.

Mais voilà le piège : les flywheels sont des dispositifs opérationnels. Ils ont besoin d’un apport régulier. On ne peut pas sauter les parties ennuyeuses. On ne peut pas être en retard. On ne peut pas aliéner son canal de distribution. On ne peut pas parier l’écosystème sur une API privée pour toujours et appeler ça une stratégie.

3dfx était roi parce qu’ils livraient une expérience fiable avant que la « fiabilité » ne devienne une discipline formelle dans le matériel PC grand public. Et 3dfx est tombé parce qu’ils ont cessé de faire fonctionner l’ensemble du business comme un système de production.

Faits et contexte à retenir

Voici des points concrets qui vous aident à raisonner sur la chute sans la transformer en mythologie.

1. Voodoo Graphics (1996) était une carte d’extension 3D uniquement — vous conserviez une carte 2D et utilisiez un câble en pass-through pour le 3D. C’était maladroit, mais ça fonctionnait.
2. Glide était une API propriétaire conçue pour être proche du matériel. Les développeurs adoraient la performance et la prévisibilité ; le marché plus tard a puni le verrouillage.
3. Direct3D a mûri rapidement à la fin des années 1990. À mesure que Microsoft itérait, le discours « écrire une fois pour le jeu sur Windows » est devenu suffisamment vrai pour nuire à Glide.
4. 3dfx a acquis STB Systems (1998) — un fabricant de cartes — se dirigeant vers l’intégration verticale et changeant les relations avec les partenaires d’add-in-board.
5. NVIDIA a itéré sans relâche, passant de RIVA 128 à TNT puis GeForce avec une cadence agressive et une exécution OEM solide.
6. Voodoo2 a popularisé le SLI (scan-line interleave), permettant à deux cartes de partager le travail de rendu. C’était ingénieux et coûteux — et pas gagnant sur la courbe de coût long terme.
7. Le Voodoo3 de 3dfx a intégré 2D et 3D, éliminant le bazar du pass-through. C’était nécessaire, mais le niveau concurrentiel montait.
8. La qualité des pilotes est devenue un différenciateur. Stabilité, compatibilité des jeux et sorties fréquentes ont commencé à compter autant que les pics de benchs.
9. L’exécution de la feuille de route de 3dfx a flanché plus tard tandis que les concurrents alignaient les sorties de silicium sur les cycles de rafraîchissement OEM — le timing est une fonctionnalité.

Une petite blague rapide, parce que l’histoire mérite une pause : le problème de 3dfx n’était pas seulement de manquer une date de sortie — c’était de traiter les dates de sortie comme des dépendances optionnelles.

Playbook de diagnostic rapide : trouver le goulot vite

Si vous enlevez la nostalgie, 3dfx a perdu parce qu’ils ne pouvaient pas maintenir la chaîne de bout en bout : de l’adoption par les développeurs à la place sur les étagères OEM en passant par la fabrication, les pilotes et le silicium de génération suivante. Voici un playbook réutilisable pour toute situation « nous avons la meilleure techno, pourquoi perdons-nous ? ».

Première étape : l’écosystème vous choisit-il ?

• Vérifiez la surface développeur : Êtes-vous la cible API/SDK par défaut ? Sinon, vous payez une taxe que vos concurrents n’ont pas.
• Vérifiez la matrice de compatibilité : Combien de bugs « fonctionne très bien sur X » sont ouverts ? Si la réponse nécessite un tableur émotionnel, vous êtes déjà en retard.
• Vérifiez la cadence des mises à jour : Livrez‑vous des correctifs chaque semaine/mois, ou des « drops » trimestriels de pilotes accompagnés de prières ?

Deuxième étape : le canal travaille‑t‑il avec vous ou autour de vous ?

• Vérifiez les design wins OEM : Si les grands constructeurs PC ne vous expédient pas par défaut, votre volume est fragile, vos marges sont des fantasmes, et votre marque effectue du travail non rémunéré.
• Vérifiez les incitations partenaires : Si vous venez de changer les règles pour vos partenaires de cartes, supposez qu’ils financeront la feuille de route de votre concurrent par dépit et survie.
• Vérifiez la prévisibilité des approvisionnements : Pouvez‑vous livrer des unités quand le marché achète ? Manquez un cycle rentrée/scolaire ou vacances et vous le ressentirez pendant des années.

Troisième étape : exécutez‑vous les parties ennuyeuses ?

• Vérifiez le débit de fabrication et QA : Un chip brillant qui arrive en retard est une rumeur, pas un produit.
• Vérifiez le risque de feuille de route : Empilez‑vous plusieurs gros changements à la fois (nouveau process, nouvelle architecture, nouvelle stratégie carte) ? Voilà comment on fabrique des retards.
• Vérifiez la trésorerie : Si votre trésorerie dépend du « flagship du prochain trimestre », vous ne faites pas de l’ingénierie — vous jouez à la roulette.

Comment 3dfx a perdu : cinq modes d’échec

1) Parier sur Glide : performance aujourd’hui, dette d’adoption demain

Glide avait du sens au départ. C’était rapide, relativement propre, et ça offrait aux développeurs une cible stable pendant que la pile 3D Windows plus large était immature. En termes ops, Glide était le protocole RPC interne qui permettait à l’équipe de livrer des fonctionnalités sans attendre un comité de standardisation. Bon mouvement — jusqu’à ce que ça ne le soit plus.

À mesure que Direct3D s’améliorait et qu’OpenGL restait pertinent pour certains usages, le monde a basculé. Les développeurs ne veulent pas trois chemins de rendu à moins que l’un d’eux leur achète un marché significatif. Une fois que les concurrents ont offert des performances « assez bonnes » sur des APIs standards, Glide est devenu un fardeau de maintenance. 3dfx portait des coûts d’intégration sur mesure tandis que les rivaux obtenaient l’écosystème gratuitement.

Ce n’est pas une question de « la propriété, c’est mal ». La propriété est acceptable quand elle vous achète du temps et que vous dépensez ce temps pour acheter le prochain avantage. La propriété est fatale quand elle devient votre identité, parce que les identités ne se refactorisent pas.

2) Intégration verticale via STB : posséder la carte, perdre le canal

Acquérir STB est le type de mouvement qui paraît rationnel sur une feuille de calcul : contrôler la fabrication, capturer la marge, assurer la qualité, coordonner les lancements. En réalité, c’est une transaction de confiance avec vos partenaires, et la confiance est une dépendance de production.

Avant STB, 3dfx vendait des puces. Les partenaires de cartes géraient l’affaire sale de construire des cartes, les distribuer, les bundler et les faire passer par le retail et les accords OEM. Après l’acquisition, ces partenaires devaient se demander : « Aidons‑nous un fournisseur, ou finançons‑nous un concurrent ? » Beaucoup ont choisi de réduire leur exposition.

Le dommage au canal est lent au début, puis soudain. Ça ressemble à une « étrange douceur de la demande », puis à une « présence concurrente inattendue », puis à un « pourquoi chaque design win OEM part ailleurs ? » Ce n’est pas un mystère ; c’est une conséquence.

3) Exécution et timing : la fonctionnalité qu’on ne peut pas benchmarquer

Dans le monde GPU, expédier quand le marché achète est un avantage brutal. Les cycles de rafraîchissement OEM, la rentrée, les ventes de fin d’année — ce sont des fenêtres temporelles. Les manquer, ce n’est pas juste perdre du CA ; c’est perdre de la notoriété et de la place en rayon. Votre concurrent devient le défaut.

3dfx avait une ingénierie solide, mais l’industrie est passée à une guerre de cadence. NVIDIA a fait de « nouveau silicium fréquemment » une habitude, puis une promesse de marque. Ça change les attentes client. Soudain, une entreprise qui livre plus lentement ne paraît pas « prudente » ; elle paraît dépassée.

4) Pilotes et compatibilité : la fiabilité est un produit

Les joueurs perçoivent les pilotes comme « la carte ». Le client moyen ne sépare pas le silicium du logiciel. Si votre GPU phare plante dans trois jeux majeurs et que celui du concurrent ne le fait pas, le concurrent est « plus rapide », même si le bench dit le contraire.

À mesure que les jeux se diversifiaient et que les APIs convergaient, la correction des pilotes et les correctifs rapides sont devenus un fossé défensif. C’est de la logique SRE : le service le plus rapide est celui qui ne vous réveille pas à 2h du matin. Le marché GPU a appris la même leçon avec un vocabulaire différent.

5) Stratégie concurrentielle : NVIDIA jouait sur l’ensemble du plateau

NVIDIA ne construisait pas seulement des GPU ; ils construisaient un modèle opérationnel. Ils comprenaient les relations OEM, les outils développeurs et les trains de sortie. Ils se sont optimisés pour l’itération et l’alignement plateforme. 3dfx s’est optimisé pour avoir raison.

Avoir raison, c’est bien. Être livrable, c’est mieux.

Deuxième petite blague (et la dernière, parce que les règles sont les règles) : Dans le hardware, « on corrigera ça en software plus tard » revient à « on corrigera ça en DNS » — c’est techniquement possible et émotionnellement coûteux.

Le miroir ops : ce que 3dfx enseigne aux SRE et aux ingénieurs stockage

Vous pouvez traiter cette histoire comme un drame tech rétro. Ou vous pouvez la traiter comme un postmortem pour le travail système moderne. Je recommande la seconde option, parce qu’elle paie le loyer.

La citation sur la fiabilité à garder sur votre mur

Idée paraphrasée de Gene Kranz : « Soyez dur et compétent. » En termes ops : ne paniquez pas et ne bricolez pas.

Leçon A : votre « stratégie API » n’est qu’une autre forme de gestion des dépendances

Glide était une dépendance. Puissante, mais qui demandait entretien, évangélisation et preuve constante qu’elle valait la complexité. Au moment où Direct3D est devenu viable, Glide devait être soit (a) graduellement déprécié, (b) transformé en détail d’implémentation derrière des standards, ou (c) rendu si convaincant qu’il devenait le standard. 3dfx n’a réussi aucune de ces fins.

Traduisez ça en ops : si vous construisez des outils internes, vous les possédez. Si vous faites de l’orchestration sur mesure, vous la possédez. Si vous construisez votre propre couche de stockage, vous la possédez. Posséder, c’est bien — jusqu’à ce que vous ne puissiez plus y allouer de personnel et que vos concurrents adoptent le chemin standard et livrent plus vite.

Leçon B : l’intégration verticale élargit le rayon d’explosion

Acheter STB n’était pas « juste » un choix de fabrication. Ça a changé les contrats, les incitations partenaires et les modes de défaillance de l’entreprise. C’est similaire à décider d’exploiter vos propres datacenters, votre distribution Kubernetes ou votre firmware SSD personnalisé. Vous pouvez le faire. Mais maintenant chaque panne est votre panne, chaque retard est votre retard, et chaque partenaire devient suspicieux de vos intentions.

Leçon C : le timing et la cadence battent l’excellence d’une seule sortie

La cadence de NVIDIA a forcé le marché à attendre des améliorations fréquentes. En opérations, la cadence, c’est votre train de sorties et votre boucle de réponse aux incidents. Si vous livrez des correctifs rarement, vous entraînez les clients à accepter la douleur. Puis un concurrent arrive et les habitue au confort. Votre churn devient une loi physique.

Leçon D : « meilleure performance » est vide sans « meilleure expérience »

Les benchs sont des tests de laboratoire. Le monde réel, ce sont des charges de travail désordonnées, des cas limites étranges et la gestion de pannes peu glamour. C’est pour ça que l’on a des SRE. La leçon de 3dfx est que les clients achètent des résultats, pas des chiffres de pic.

Trois mini-récits d’entreprise venus des tranchées

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait une chaîne de rendu accélérée par GPU pour du rendu et de l’inférence ML. Elle gérait deux fournisseurs en parallèle, et l’équipe supposait que « CUDA vs non‑CUDA » était le seul différenciateur important. L’hypothèse : une fois que le SDK du fournisseur fonctionne, le matériel est interchangeable.

Ils ont signé un accord d’approvisionnement basé sur des benchs de débit maximal issus d’un seul test propre. Puis ils ont déployé les nouvelles cartes dans un cluster où les jobs étaient rafales et les schémas d’allocation mémoire chaotiques. En quelques jours, la latence de queue a explosé et le scheduler de jobs a commencé à thrash. L’équipe a accusé Kubernetes, puis le noyau, puis le « bruit aléatoire ».

Le vrai problème était le comportement du pilote sous pression mémoire combiné à une interaction subtile dans leur runtime de conteneur. Le pilote du nouveau fournisseur récupérait différemment des échecs d’allocation transitoires. Ce n’était pas « pire » en bench ; c’était pire dans leur réalité de production.

La correction a exigé de figer les versions de pilotes, modifier les règles de packing des jobs et créer une piscine canari avec une matrice de compatibilité stricte. L’essentiel : ils ont arrêté de supposer qu’un GPU est un GPU. Les écosystèmes sont des produits, pas des accessoires.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une société d’e‑commerce a décidé « d’optimiser » son stockage d’artefacts en dédupliquant agressivement et en passant à une mise en page compressée sur le filesystem. Le but était noble : réduire les coûts de stockage et accélérer les téléchargements en mettant plus d’artefacts en cache sur moins de nœuds NVMe.

Ils ont déployé le changement rapidement, utilisant un index basé sur hash tenu en mémoire puis périodiquement flushé sur disque. Les tests de charge semblaient excellents. En production, les pics nocturnes de CI ont causé une tempête : les compactions ont chevauché le trafic de lecture de pointe, saturant les I/O et augmentant les temps de build. Les développeurs ont été les premiers à remarquer, puis les dirigeants. Tout le monde a fait le calcul, et le résultat était moche.

Le retour de bâton n’était pas l’idée de compression ou de déduplication. C’était de le faire sans isolation I/O stricte et sans modéliser le comportement de compaction comme une charge de travail de première classe. Ils ont optimisé pour le cas moyen et payé sur la queue.

La correction a été douloureusement banale : séparer les nœuds de compaction des nœuds de lecture, définir des cgroups I/O explicites et limiter le débit des travaux de maintenance. Ils ont aussi appris à traiter le travail d’arrière-plan comme du travail de production avec un SLO.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe de services financiers exploitait une flotte de nœuds de traitement de données avec des SSDs locaux et un store d’objets répliqué. Rien de fancy. La pratique ennuyeuse : des répétitions hebdomadaires de reprise après sinistre où ils faisaient réellement échouer un nœud, restauraient depuis la sauvegarde et validaient les checksums de bout en bout.

Un jour, un bug de firmware a fait que certains SSDs ont commencé à générer des erreurs non récupérables sous un motif d’écriture spécifique. Pas tous en même temps — juste assez pour corrompre silencieusement quelques objets avant que les couches supérieures ne s’en rendent compte.

Parce que l’équipe avait répété les exercices, ils n’ont pas débattu de la marche à suivre. Ils ont mis en quarantaine les nœuds affectés, gratté les répliques, restauré des copies propres et remplacé le firmware sur les appareils restants. L’incident a quand même fait mal, mais ce n’est pas devenu un article.

La leçon est offensivement simple : répétez. La fiabilité n’est pas un document ; c’est une habitude.

Tâches pratiques : commandes, sorties et décisions

La chute de 3dfx est une histoire de stratégie, mais la stratégie échoue par la mécanique : cycles manqués, pilotes instables, accrocs d’approvisionnement et performances opaques. Les tâches ci‑dessous sont les mécaniques que vous devriez exécuter dans votre monde — parce que votre concurrent l’a déjà fait.

Tâche 1 : Identifier le GPU et la version du pilote (vérité de 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 |
+-------------------------------+----------------------+----------------------+

Ce que ça signifie : Vous connaissez maintenant la version exacte du pilote et si vous êtes proche des limites de puissance/mémoire.

Décision : Si les incidents coïncident avec des changements de pilote, figez cette version et testez les montées de version d’abord dans une piscine canari.

Tâche 2 : Vérifier la largeur/vitesse du lien PCIe (le tueur silencieux de débit)

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)

Ce que ça signifie : La carte est capable de PCIe Gen4 x16, mais fonctionne en Gen3 x8.

Décision : Inspecter les paramètres BIOS, les risers, le câblage du slot ou le throttling thermique. « Ça bench bien parfois » est la façon dont ça se cache.

Tâche 3 : Confirmer que le pilote kernel est chargé et sain

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

Ce que ça signifie : Les modules attendus sont chargés ; s’ils manquent, vous n’utilisez pas le GPU que vous croyez utiliser.

Décision : Si un module clignote après des mises à jour, figez la combo kernel/driver et planifiez des rollouts contrôlés.

Tâche 4 : Lire les logs du noyau pour resets GPU ou erreurs 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.

Ce que ça signifie : « GPU has fallen off the bus » n’est pas un bug applicatif. C’est de la stabilité : alimentation, thermiques, firmware ou intégrité PCIe.

Décision : Escaladez vers hardware/firmware ; réduisez le power cap ; vérifiez câbles/risers ; mettez le nœud en quarantaine.

Tâche 5 : Vérifier la marge thermique (les chutes de performance existent)

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

Ce que ça signifie : Vous êtes proche de la température de ralentissement et de la limite de puissance ; les clocks peuvent déjà être contraints.

Décision : Améliorer le refroidissement, augmenter la courbe de ventilation, réduire l’ambiance ou limiter la puissance pour la stabilité. Une performance constante vaut mieux que des pics héroïques.

Tâche 6 : Identifier saturation CPU vs saturation 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

Ce que ça signifie : Le CPU est chaud ; si l’utilisation GPU est basse, le goulot est probablement côté CPU (prétraitement) ou un choke mono‑thread.

Décision : Profilez la pipeline, augmentez le parallélisme ou déplacez les étapes CPU hors du chemin critique.

Tâche 7 : Vérifier la latence stockage (parce que « GPU lent » est souvent « disque lent »)

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

Ce que ça signifie : Le NVMe est proche de 98% d’utilisation et les await sont à deux chiffres. C’est la latence que ressent votre pipeline.

Décision : Ajoutez des périphériques, séparez lectures/écritures, ajustez la profondeur de file d’attente ou mettez en cache les entrées. Ne « optimisez pas le code GPU » pendant que le stockage hurle.

Tâche 8 : Trouver rapidement les plus gros consommateurs I/O

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

Ce que ça signifie : Votre « job GPU » inclut du prétraitement CPU et de la compression qui peuvent dominer l’I/O.

Décision : Déplacez la compression hors‑nœud, limitez‑la ou planifiez‑la en dehors des fenêtres d’inférence/entraînement de pointe.

Tâche 9 : Valider l’espace système de fichiers et la marge d’inodes (la panne stupide)

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

Ce que ça signifie : La racine est à 97% ; vous êtes à un storm de logs d’applications qui échouent de façons créatives.

Décision : Libérez de l’espace, faites pivoter les logs ou déplacez les chemins à écriture intensive hors de la racine. Ensuite, posez des alertes à 80/90/95% avec un humain en on‑call.

Tâche 10 : Vérifier les pertes/retransmissions réseau (parce que les pipelines distribués ment)

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

Ce que ça signifie : Des drops RX à grande échelle peuvent se traduire par de la lenteur « aléatoire » ou des timeouts en amont.

Décision : Inspectez les buffers NIC, la congestion du switch, les mismatches MTU ou le QoS. Ne blâmez pas l’application tant que les paquets ne se comportent pas.

Tâche 11 : Confirmer que DNS et discovery ne sont pas le goulot

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

Ce que ça signifie : Un nombre élevé de misses par rapport aux hits peut indiquer des clients bavards ou un mauvais caching ; les délais DNS peuvent amplifier la latence queue.

Décision : Ajoutez du cache, réduisez la fréquence des requêtes ou corrigez le comportement client. « C’est juste le DNS » devient « c’est toujours le DNS » étonnamment souvent.

Tâche 12 : Suivre la pression mémoire au niveau processus et le risque OOM

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

Ce que ça signifie : Seulement 18Gi disponibles sur un système de 503Gi suggère que vous êtes à une rafale d’un reclaim ou d’un OOM kill.

Décision : Fixez des limites mémoire, réduisez les jobs concurrents, ajoutez du swap (prudemment) ou scalez horizontalement. Évitez le « on met juste une machine plus grosse » sans comprendre la forme d’utilisation mémoire.

Tâche 13 : Vérifier les signaux de throttling noyau et de pression (réalité moderne)

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

Ce que ça signifie : La pression IO « full » indique des périodes où les tâches sont bloquées sur l’I/O. C’est une taxe de latence sur tout le système.

Décision : Réduisez la contention I/O, isolez les charges ou provisionnez plus de bande passante. Ne peaufinez pas les kernels GPU pendant que l’OS attend le stockage.

Tâche 14 : Valider que la maintenance de fond ne vous bouffe pas

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

Ce que ça signifie : Compression et reclaim consomment massivement du CPU. Votre « charge principale » se bat avec la housekeeping.

Décision : Limitez le débit des maintenances, utilisez des cgroups ou planifiez les travaux d’arrière‑plan en dehors des pics. C’est la version opérationnelle de « l’intégration verticale » : vous portez les conséquences.

Erreurs courantes : symptôme → cause racine → correction

Cette section est l’endroit où la nostalgie meurt et la mémoire musculaire se forme.

1) Symptom : « Nous avons le hardware le plus rapide, mais les développeurs nous ignorent »

Cause racine : Votre surface plateforme est non standard, coûteuse à cibler ou mal outillée. Les avantages à la Glide deviennent des passifs Glide.

Correction : Supportez bien les standards dominants, fournissez d’excellents outils et faites du « happy path » le défaut. Les chemins propriétaires rapides doivent être optionnels et additifs.

2) Symptom : « Nous livrons d’excellents produits mais ratons des trimestres »

Cause racine : La cadence de sortie n’est pas gérée comme un système : les dépendances s’empilent, le risque est couplé et il n’y a pas de plan crédible pour les glissements.

Correction : Scindez la feuille de route en livrables plus petits, imposez des gates de stade et alignez les lancements sur les fenêtres du marché. Le timing est une exigence, pas une préférence.

3) Symptom : « Les partenaires ont cessé de pousser notre produit »

Cause racine : Les incitations se sont brisées. Souvent causé par l’intégration verticale, le conflit de canal ou l’approvisionnement imprévisible.

Correction : Restaurez la confiance via des programmes partenaires clairs, des prix stables et des allocations prévisibles. Si vous passez en direct, soyez honnête et investissez en conséquence — ne le faites pas à moitié.

4) Symptom : « Les benchs sont bons, mais les clients se plaignent de stutter/crash »

Cause racine : Dette de pilotes et de compatibilité. La longue traîne des jeux/apps vous punira.

Correction : Construisez un labo de compatibilité, priorisez les charges top, publiez des pilotes fréquents et instrumentez la télémétrie de crash. Le travail de fiabilité est du travail produit.

5) Symptom : « Nous optimisons le coût et devenons plus lents »

Cause racine : Les travaux d’arrière‑plan et les compactions/maintenances entrent en collision avec la demande de pointe. L’optimisation a déplacé le goulot.

Correction : Isolez la maintenance, limitez son débit et mesurez la latence queue. Si vous ne pouvez pas le grapher, vous ne pouvez pas lui faire confiance.

6) Symptom : « Tout allait bien, puis soudain nous sommes hors-jeu »

Cause racine : Cadence concurrentielle et changements de plateforme. Une API standard mûrit, les deals OEM se déplacent et votre différenciation s’évapore.

Correction : Surveillez les indicateurs avancés : adoption développeur, design wins OEM, cadence des pilotes, fiabilité de l’approvisionnement. N’attendez pas que le revenu vous dise la vérité.

Listes de vérification / plan étape par étape

Checklist 1 : Si vous pariez sur une techno propriétaire (le piège Glide)

1. Définissez le plan d’abandon dès le jour un : comment dégrader gracieusement vers les standards.
2. Mesurez l’adoption chaque mois : nombre d’intégrations de première classe, pas « d’intérêt ».
3. Budgetez le travail de compatibilité comme une équipe permanente, pas un rush de lancement.
4. Livrez une suite de conformité pour que les partenaires puissent valider sans vous supplier.
5. Rendez votre voie propriétaire optionnelle : l’API standard doit rester excellente.

Checklist 2 : Si vous considérez l’intégration verticale (la leçon STB)

1. Listez les partenaires qui perdent de la marge si vous intégrez ; supposez qu’ils réagiront.
2. Décidez si vous acceptez de les perdre. Si non, n’intégrez pas.
3. Construisez un modèle d’approvisionnement avec scénarios de « trimestre manqué » ; planifiez la trésorerie en conséquence.
4. Investissez dans le débit QA et l’analyse des défaillances ; sinon vous venez d’acheter de la douleur.
5. Communiquez tôt et clairement ; l’ambiguïté engendre le sabotage du canal.

Checklist 3 : Cadence opérationnelle pour une pile matérielle/logicielle compétitive

1. Train de sorties hebdomadaire pilotes/outils avec canaris et rollback.
2. Suivi de matrice de compatibilité : top 50 workloads doivent être verts.
3. Dashboards de performance : médiane et p99, pas seulement FPS/throughput peak.
4. Télémétrie supply et fabrication : lead times, risque rendement, risque allocation.
5. Revue d’incident qui se termine par un changement dans la façon dont vous livrez, pas juste un PDF.

Étape par étape : trier une situation « nous perdons des parts malgré une bonne techno »

1. Cartographiez la pipeline : développeur → SDK/API → pilote → matériel → carte/OEM → retail/expédition. Marquez les transferts.
2. Choisissez trois indicateurs avancés : cibles développeur, design wins OEM, taux de crash pilotes.
3. Réalisez un audit de cadence : à quelle fréquence livrez‑vous des correctifs ? Et vos concurrents ?
4. Trouvez le point de congestion : ce n’est généralement pas le silicium. C’est la compatibilité, l’approvisionnement ou la confiance du canal.
5. Corrigez une couche à la fois : coupler des corrections en un « big bang » est la façon de recréer la pile de risques en fin de vie de 3dfx.

FAQ

3dfx a‑t‑il perdu parce que NVIDIA avait une « meilleure technologie » ?

Pas uniquement. NVIDIA a exécuté une cadence plus rapide, un alignement OEM plus fort et une stratégie d’écosystème plus large. La technologie importait, mais le modèle opérationnel a compté davantage.

Glide était‑il une erreur ?

Au début, non. C’était un raccourci pragmatique qui apportait une excellente expérience quand les standards étaient immatures. L’erreur a été d’en faire une douve permanente plutôt qu’un avantage temporaire.

Pourquoi l’acquisition de STB a‑t‑elle autant nui ?

Elle a changé les incitations. Les partenaires de cartes qui amplifiaient auparavant 3dfx devaient désormais concurrencer avec eux. Dans le hardware, la confiance du canal est un composant de la chaîne d’approvisionnement.

Quel rôle Direct3D a‑t‑il joué dans la chute ?

À mesure que Direct3D a mûri, il a réduit la valeur d’une API propriétaire. Les développeurs pouvaient cibler un standard et atteindre la majorité des clients avec des performances acceptables.

Les pilotes importaient‑ils vraiment autant à la fin des années 1990 ?

Oui, et de plus en plus. À mesure que les jeux se diversifiaient et que les piles OS évoluaient, la compatibilité et la stabilité sont devenues l’expérience utilisateur quotidienne. La fiabilité est devenue une fonctionnalité produit.

Quelle est la leçon SRE dans l’échec d’une entreprise de GPU grand public ?

La fiabilité de bout en bout gagne des marchés. Un composant rapide dans un système non fiable ne crée pas un produit fiable. Traitez la distribution, les outils et le support comme des dépendances de production de première classe.

3dfx aurait‑il pu survivre en restant seulement fabricant de puces et en ne fabriquant pas de cartes ?

C’est possible. Rester producteur de puces seulement aurait réduit le conflit de canal et permis aux partenaires de cartes de continuer à pousser le produit. Cela n’aurait pas résolu tous les problèmes, mais aurait éliminé une blessure auto‑infligée majeure.

L’intégration verticale est‑elle toujours mauvaise ?

Non. C’est puissant quand vous pouvez exécuter la fabrication, la QA et la distribution à grande échelle. C’est mauvais quand elle est utilisée pour « réparer » un problème de canal au lieu d’ajuster les incitations et la cadence.

Quel est l’équivalent moderne du piège Glide ?

Une couche de plateforme propriétaire que les développeurs doivent adopter pour obtenir la « pleine performance », tandis que les chemins basés sur les standards traînent. Ça marche jusqu’à ce qu’un concurrent rende le chemin standard suffisamment bon et plus simple.

Conclusion : prochaines étapes pratiques

3dfx est le récit édifiant pour chaque équipe qui croit que l’excellence technique se convertit automatiquement en puissance de marché. Ce n’est pas automatique. Ni pour les GPU, ni pour les systèmes distribués, ni pour le stockage, ni pour les plateformes.

Si vous voulez éviter le même type de chute — que vous livriez du silicium, du logiciel ou « juste » une plateforme interne — faites trois choses ce trimestre :

1. Mesurez la santé de l’écosystème : adoption, compatibilité et cadence. Si vous ne pouvez pas le quantifier, vous gérez les vibes.
2. Auditez votre canal et vos incitations : partenaires, clients internes et équipes adjacentes. Si quelqu’un perd quand vous gagnez, il finira par vous faire perdre.
3. Faites de la fiabilité un critère de sortie : stabilité des pilotes, sécurité des upgrades, capacité de rollback et approvisionnement/prévisibilité de débit. La vitesse sans stabilité n’est qu’une manière plus rapide de s’écraser.

La partie la plus triste de 3dfx n’est pas qu’ils ont perdu. Beaucoup d’entreprises perdent. Le triste, c’est qu’ils ont perdu alors qu’ils détenaient l’avance précieuse que la plupart des équipes tueraient pour avoir — et qu’ils l’ont saignée via des modes d’échec opérationnels évitables.