En 1999 Microsoft financió un benchmark que enfrentaba Windows NT Server 4.0 con Linux 2.2.2. El resultado cayó como una bomba en la comunidad: Windows aparecía como 2,5 veces más rápido sirviendo archivos y 3,7 veces más rápido como servidor web. Las críticas contra la metodología y contra Mindcraft, la empresa que realizó las pruebas, fueron inmediatas. Dos meses después el experimento se repitió con ingenieros de Red Hat presentes y bajo supervisión de PC Week Labs. Windows volvió a ganar. Esta vez la explicación ya no podía reducirse al patrocinador: Linux tenía problemas reales de escalabilidad SMP y red.
Las claves del benchmark que puso a Linux contra las cuerdas en 30 segundos
- Microsoft pagó en 1999 una comparativa entre Windows NT Server y Linux 2.2.2 realizada por Mindcraft.
- La primera prueba favoreció claramente a Windows y fue cuestionada por cómo se había configurado Linux.
- PC Week Labs repitió después las mediciones con Red Hat, Microsoft y Mindcraft presentes.
- Windows volvió a ganar, aunque con diferencias menores y sin algunos de los fallos observados inicialmente.
- El episodio ayudó a identificar cuellos de botella SMP y de red que Linux corrigió durante los meses siguientes.
La historia resulta especialmente interesante vista desde 2026 porque Linux domina una parte enorme de la infraestructura de servidores, cloud y supercomputación. Pero esa posición no estaba garantizada a finales de los noventa.
Linux 2.2 acababa de aparecer y una de sus grandes promesas era mejorar el soporte para sistemas multiprocesador. Los servidores de cuatro CPU comenzaban a ser máquinas relevantes para cargas empresariales y Microsoft llevaba tiempo optimizando Windows NT precisamente para este tipo de hardware.
Ahí apareció Mindcraft.
El benchmark estaba pagado por Microsoft y Linux salió muy mal parado
Mindcraft publicó el 13 de abril de 1999 una comparación realizada sobre un servidor Dell con cuatro procesadores Pentium II Xeon y cuatro interfaces Fast Ethernet.
Las pruebas utilizaban Windows NT Server 4.0 frente a Red Hat Linux 5.2 actualizado al kernel 2.2.2. Para medir servidor de archivos se utilizó Samba y para HTTP, Apache.
El propio informe reconocía quién había financiado el trabajo: Microsoft Corporation patrocinó las pruebas.
Eso no convertía automáticamente los resultados en falsos, pero había motivos técnicos para cuestionar la comparación.
Windows había recibido ajustes específicos para aprovechar la máquina. Entre ellos figuraba la afinidad entre adaptadores de red y procesadores y modificaciones en diferentes parámetros de red.
La configuración de Linux era mucho menos elaborada. El entorno se apoyaba en un kernel muy reciente, Apache y Samba sin una optimización equivalente y, sobre todo, en una infraestructura de red del kernel 2.2 que todavía tenía dificultades para escalar cuando varias CPU y varias interfaces generaban tráfico simultáneamente.
El resultado publicado fue contundente: NT alcanzaba aproximadamente 2,5 veces el rendimiento de Linux como servidor de archivos y 3,7 veces como servidor web.
La reacción fue inmediata.
Alan Cox, una de las figuras principales en el desarrollo del kernel Linux de aquella época, criticó la metodología y la falta de acceso inicial al sistema utilizado. También cuestionó la credibilidad de Mindcraft para resolver por sí sola la discusión sobre el rendimiento de Linux frente a NT.
Otros desarrolladores detectaron problemas similares. Una de las críticas centrales era razonable: Microsoft había proporcionado el hardware, financiado el estudio y disponía de experiencia para ajustar su propio sistema, mientras Linux no había sido configurado por especialistas equivalentes.
Incluso PC Week resumió posteriormente el problema de una forma bastante clara: Microsoft había pagado la prueba y había podido optimizar NT, mientras Mindcraft no había encontrado inicialmente a una persona equivalente para ajustar Linux.
La discusión podría haber terminado ahí, convertida en otra batalla de relaciones públicas entre Microsoft y el software libre.
No ocurrió.
Red Hat entró en el laboratorio y Windows volvió a ganar
Bruce Weiner, presidente de Mindcraft, publicó el 4 de mayo una invitación para repetir el benchmark de forma abierta.
La primera propuesta tampoco convenció a los principales representantes de Linux. Alan Cox pidió que las pruebas fueran realizadas por otra organización y Bob Young, entonces presidente de Red Hat, defendió la participación de un laboratorio reconocido e independiente.
La solución terminó siendo PC Week Labs, el laboratorio de Ziff-Davis en Foster City, California.
En junio de 1999 representantes de Red Hat, Microsoft, Penguin Computing y Mindcraft participaron en una nueva ronda de pruebas. Esta vez los especialistas de Linux podían modificar y optimizar su propia configuración.
La situación era mucho más difícil de descartar como propaganda.
El nuevo benchmark corrigió varios de los problemas señalados en abril y las diferencias cambiaron. Linux ya no sufría el desplome que había aparecido en determinadas cargas durante la primera prueba y su rendimiento con poca carga era mucho más competitivo.
Pero cuando entraban en juego varias CPU y cargas de red elevadas, NT seguía por delante.
PC Week Labs concluyó que Windows NT 4.0 continuaba superando a Linux con Apache y Samba en las categorías probadas. La frase más incómoda para la comunidad Linux era que, en varios de los puntos donde se había acusado a Mindcraft de manipular la prueba, las explicaciones propuestas no justificaban finalmente la diferencia de rendimiento.
Eso no significaba que el primer benchmark fuese perfecto.
The Register destacó entonces una diferencia importante: en la repetición Linux no colapsaba al aumentar el número de clientes y las ventajas obtenidas por Windows eran menores que las publicadas inicialmente por Mindcraft. En sistemas de una sola CPU, además, la distancia disminuía considerablemente.
La conclusión era bastante más interesante que «Microsoft tenía razón» o «el benchmark estaba amañado».
La primera prueba tenía problemas metodológicos, pero había encontrado al mismo tiempo una debilidad auténtica de Linux.
El cuello de botella estaba dentro del kernel
Uno de los problemas aparecía en la forma en que Linux 2.2 procesaba tráfico de red en máquinas SMP, es decir, sistemas con varios procesadores.
El servidor del benchmark utilizaba cuatro tarjetas Fast Ethernet y cuatro CPU. Era precisamente el tipo de configuración capaz de exponer un diseño que funcionaba correctamente con una CPU pero tenía dificultades cuando varios procesadores intentaban trabajar simultáneamente.
El análisis posterior identificó tiempo consumido alrededor de synchronize_bh(), relacionado con el mecanismo de bottom halves utilizado entonces para aplazar parte del procesamiento generado por las interrupciones de red.
El problema práctico era que buena parte de ese trabajo no podía escalar de forma paralela con las cuatro CPU. Las tarjetas podían entregar paquetes rápidamente, pero determinadas partes del procesamiento de red terminaban serializadas.
La revisión histórica del benchmark de Dan Kegel recoge precisamente este cuello de botella y las investigaciones de Zach Brown durante las pruebas.
Meses después el propio desarrollo del kernel atacó ese problema.
Uno de los cambios más importantes fue softnet, una profunda remodelación de la infraestructura de red que terminó incorporándose al kernel de desarrollo Linux 2.3.43 en febrero de 2000.
Softnet introdujo, entre otras cosas, colas de trabajo de red por CPU, lo que permitía que distintos procesadores participaran simultáneamente en el procesamiento de paquetes. Posteriormente Linux añadió también mecanismos de afinidad de interrupciones.
No fue el único cuello de botella.
En abril de 2000 apareció otra discusión en la lista de desarrollo del kernel alrededor del Big Kernel Lock y poll().
poll() es una llamada utilizada por servidores para comprobar qué descriptores tienen actividad pendiente. En una máquina manejando miles de conexiones, obligar a varios procesadores a pasar por un bloqueo global podía convertirse en otro punto de serialización.
Manfred Spraul propuso eliminar ese bloqueo alrededor de poll(). Linus Torvalds revisó las implementaciones y respaldó finalmente la modificación, señalando que la mayoría ya podían funcionar correctamente sin ese bloqueo global.
La discusión es un buen ejemplo de lo que realmente significaba optimizar Linux para servidores SMP en aquella época: no bastaba con reconocer cuatro procesadores. Había que eliminar uno a uno los lugares del kernel donde esos cuatro procesadores terminaban esperando el mismo recurso.
Un año después los números eran completamente diferentes
Quizá la parte más llamativa de la historia aparece al mirar los benchmarks de 2000.
No sirve para hacer una comparación directa con Mindcraft porque tanto el software como el hardware y el benchmark habían cambiado. Pero sí permite observar a qué velocidad estaba evolucionando la pila Linux.
En abril de 2000 Dell realizó una prueba oficial SPECweb99 con un PowerEdge 6400 equipado con cuatro Pentium III Xeon a 700 MHz, Windows 2000 Advanced Server e IIS 5.0.
El resultado certificado fue 1.598 SPECweb99.
Dos meses después una configuración del mismo modelo de servidor Dell, también con cuatro Pentium III Xeon a 700 MHz, consiguió 4.200 SPECweb99 utilizando Red Hat Linux 6.2 y TUX 1.0.
| SPECweb99 en Dell PowerEdge 6400/700 | Resultado |
|---|---|
| Windows 2000 Advanced Server + IIS 5.0 | 1.598 |
| Red Hat Linux 6.2 + TUX 1.0 | 4.200 |
Hay que evitar una conclusión demasiado fácil.
TUX era un servidor HTTP desarrollado para obtener alto rendimiento y ejecutaba parte de su trabajo dentro del kernel. Las configuraciones no eran idénticas en todos sus componentes y estos resultados no demuestran que Linux se volviese universalmente 2,6 veces más rápido que Windows en apenas un año.
Sí muestran algo más relevante: el techo de escalabilidad que había quedado expuesto en 1999 ya no era el mismo.
Linux había cambiado.
Linus Torvalds reconocería después que, aunque en el benchmark original se habían elegido condiciones particularmente favorables para NT, buena parte del resultado era real. Su lectura terminó siendo pragmática: Microsoft había encontrado áreas donde Linux funcionaba mal y eso proporcionaba problemas concretos que podían corregirse.
El benchmark no demostró que Windows fuese mejor que Linux
Veintisiete años después resulta tentador convertir esta historia en una revancha.
Microsoft pagó una prueba, Linux perdió, los desarrolladores se enfadaron, arreglaron el kernel y terminaron ganando otros benchmarks.
La realidad es más útil que ese relato.
Mindcraft hizo una prueba con una carga, una configuración de hardware, unas versiones concretas de software y unas condiciones determinadas. Windows NT estaba muy optimizado para aquella combinación y Linux 2.2 no.
El patrocinio de Microsoft, el ajuste desigual de los sistemas y algunas anomalías de la primera prueba justificaban el escrutinio. La repetición independiente también demostró que no bastaban para explicar todo lo ocurrido.
Había problemas auténticos de escalabilidad en Linux.
Los desarrolladores acabaron encontrándolos en subsistemas poco visibles para el usuario: procesamiento de interrupciones, red SMP, colas globales y bloqueos compartidos.
Ahí está probablemente la parte más interesante de aquel episodio para quienes administran sistemas o desarrollan software actualmente.
Un benchmark puede estar seleccionado para favorecer una determinada arquitectura y seguir señalando un problema real. Criticar su metodología es necesario, pero reproducir el resultado, perfilar el sistema y encontrar dónde se pierden los ciclos suele ser bastante más útil que discutir sobre quién pagó la prueba.
En 1999 Linux hizo ambas cosas. Primero discutió. Después abrió el profiler.
Y la segunda parte fue la que terminó cambiando el kernel.
