Linux Benchmarking CÓMO

por André D. Balsa, andrewbalsa@usa.net
Traducido por: Joaquín Cuenca Abela, jcuenca@patan.eleinf.uv.es

v0.12, 15 de Agosto de 1997
El Linux Benchmarking CÓMO trata sobre algunos aspectos asociados con el benchmarking en los sistemas Linux y presentas unas herramientas (algo toscas) para realizar medidas del rendimiento de su sistema, que podría proporcionar una cantidad significativa de información en un par de horas. Quizás también ayude a hacer que disminuya el número de artículos sobre el tema que se envían a comp.os.linux.hardware...

1. Introducción

"Lo que no podemos decir acerca de nosotros mismos debería desaparecer en el silencio."

Ludwig Wittgenstein (1889-1951), filósofo austríaco

Benchmarking significa medir la velocidad con la que un ordenador ejecuta una tarea, de forma que se puedan realizar comparaciones entre diferentes combinaciones de programas/componentes. Esta definición no tiene en cuenta la sencillez de utilización, estética o ergonomía o cualquier otro tipo de juicio subjetivo.

El Benchmarking es una tarea repetitiva, tediosa, y hay que llevar cuidado con los detalles. Es muy normal que los resultados no sean los que uno espera y que estén sujetos a interpretación (puede que hoy en día ésta sea la parte más importante).

Para finalizar, el benchmarking trata con hechos y datos, no con opiniones ni aproximaciones.

1.1 ¿Por qué el benchmarking es tan importante?

Aparte de las razones apuntadas en el BogoMips Mini-CÓMO (sección 8, párrafo 2), podemos tener que ceñirnos a un presupuesto y/o satisfacer unas necesidades de rendimiento mientras instalamos un sistema Linux. En otras palabras, cuando tenemos que hacernos las siguientes preguntas:

tendremos que examinar, comparar y/o crear benchmarks. Minimizar costes sin tener que mantener un rendimiento en particular implica utilizar una máquina con partes desfasadas (aquel viejo 386SX-16 que está tirado en el garaje podría servir) y no necesita bechmarks, y maximizar el rendimiento sin que importe el dinero no es una situación muy realista (a menos que quiera poner un Cray en su casa - la unidad de alimentación recubierta con cuero es bonita, ¿verdad?).

El benchmarking de por si no tiene sentido, y es una estúpida pérdida de tiempo y dinero; solo tiene sentido como una parte de un proceso, i.e. si tiene que hacer una elección entre dos o más alternativas.

Normalmente otro parámetro a tener en cuenta en el proceso de decisión es el coste, pero también la disponibilidad, el servicio, la seguridad, estrategia o cualquier otra característica medible y racional que tenga que ver con un ordenador. Por ejemplo, cuando comparamos el rendimiento de diferentes versiones del núcleo de Linux, la estabilidad suele ser más importante que la velocidad.

1.2 Consideraciones no válidas en la medida del rendimiento

Se pueden leer muy amenudo en los grupos de noticias y las listas de correo, pero aun así:

  1. Reputación del fabricante (no se puede medir y es insensato).
  2. Cuota de mercado del fabricante (insensato e irrelevante).
  3. Parámetros irracionales (por ejemplo, supersticiones o prejuicios: ¿Compraría un procesador que se llame 131313ZAP pintado de rosa?)
  4. Valor estimado (insensato, irracional y no se puede medir).
  5. Cantidad de propaganda: creo que éste es la peor. Personalmente, estoy harto de los logos ``XXX inside'' o ``kkkkkws compatible'' (ahora se ha unido a la banda el ``aaaaa Powered'' - ¿Quién será el próximo?). EMMO
    N.T.: En Mi Modesta Opinión
    , los billones de pesetas gastados en campañas de este tipo estarían mejor empleados en equipos de investigación que se ocupen de desarrollar nuevos procesadores libres de fallos, más rápidos y más baratos :-). Ningún tipo de publicidad puede arreglar un fallo en la unidad de coma flotante en la nueva hornada de procesadores que acaba de instalar en su placa base, pero en cambio un procesador rediseñado sí puede hacerlo.
  6. La opiniones del tipo ``tiene lo que paga'' son sólo eso: opiniones. Denme hechos, por favor.

2. Procedimientos de medida e interpretación de resultados

Un cuantas recomendaciones semiobvias:

  1. Primera y principal, identifique el rendimiento objetivo. ¿Qué es exactamente lo que trata de medir? ¿De qué forma la medida del rendimiento le ayudará después a tomar una decisión? ¿Cuánto tiempo y cuántos recursos está dispuesto a gastar en el proceso de medida?
  2. Utilice herramientas estándar. Use una versión del núcleo estable y actualizada, así como un gcc, libc, y una herramienta de medida del rendimiento actualizados y estándares. Abreviando, utilice el LBT (ver más adelante).
  3. De una descripción completa de su configuración (vea el artículo LBT más adelante).
  4. Trate de aislar una variable. Las medidas comparativas dan más información que las ``absolutas''. Ya no puedo insistir más en este punto.
  5. Verifique sus resultados. Ejecute sus pruebas unas cuantas veces y compruebe las fluctuaciones en los resultados, de haberlas. Las fluctuaciones inexplicables invalidarán sus resultados.
  6. Si cree que su esfuerzo en la medición del rendimiento ha producido información útil, compártala con la comunidad Linux de forma breve y concisa.
  7. Por favor, olvídese de los BogoMips. Me he prometido que algún día implementaré un rapidísimo ASIC con el bluque de los BogoMips enganchado en él. ¡Entonces veremos lo que tengamos que ver!

2.1 Entendiendo la elección de la herramienta

Las herramientas de medida sintéticas vs. las de aplicaciones

Antes de perder el tiempo escogiendo entre todos los tipos de herramientas de medida, se debe hacer una elección básica entre las herramientas ``sintéticas'' y las de ``aplicación''.

Las herramientas sintéticas están especialmente diseñadas para medir el rendimiento de un componente individual de un ordenador, normalmente llevando el componente escogido a su máxima capacidad. Un ejemplo de una herramienta sintética muy conocida es el Whetstone, programado originalmente en 1972 por Harold Curnow en FORTRAN (¿o fue en ALGOL?) y todavía ampliamente utilizada. El conjunto de herramientas Whestone medirá el rendimiento de la unidad de punto flotante de la CPU.

La crítica principal que puede hacersele a las medidas ``sintéticas'' es que no representan el rendimiento del sistema en las situaciones de la vida real. Tomemos por ejemplo las herramientas Whetstone: el blucle principal es muy pequeño y podría caber fácilmente en la caché primaria de la CPU, manteniendo el bus de la unidad de punto flotante (FPU) constantemente lleno y ejercitando, por tanto, la FPU a su máxima velocidad. No podemos criticar las herramientas Whetstone por ésto, ya que hemos de tener presente que fueron programadas hace 25 años (¡y diseñadas en fechas anteriores a ésta!), pero hemos de asegurarnos de que interpretamos los resultados con cuidado cuando medimos microprocesadores modernos.

Otro punto a tener en cuenta sobre los tests sintéticos es que, idealmente, deberían darnos información acerca de un aspecto específico del sistema que estamos comprobando, independientemente del resto de componentes: un test sintético sobre la E/S de las tarjetas Ethernet debería devolver el mismo resultado (o al menos similar) independientemente de si se ejecuta en un 386SX-16 con 4 MBytes de RAM o de si se ejecuta en un Pentium 200 MMX con 64 MBytes de RAM. Sin embargo, el test medirá la rendimiento global de la combinación CPU/placa base/Bus/tarjeta Ethernet/Subsistema de memoria/DMA: no es muy útil, ya que la variación en el procesador podría causar un impacto mayor en los resultados que la variación en la tarjeta de red Ethernet (naturalmente, ésto es suponiendo que estamos utilizando la misma combinación de controlador/núcleo, que también pueden producir grandes cambios).

Para terminar, un error muy común es hacer la media de varios tests sintéticos y decir que esta media es una buena representación del rendimiento en la vida real de un sistema.

Aquí tenemos un comentario acerca de los tests FPU, citado con permiso de Cyrix Corp.:

``Una Unidad de Coma Flotante (Floating Point Unit, FPU) acelera los programas diseñados para utilizar matemáticas en coma flotante: típicamente programas de CAD, hojas de cálculo, juegos 3D y diseño de aplicaciones. Sin embargo, hoy en día las aplicaciones más populares para PC utilizan al mismo tiempo instrucciones en enteras y en coma flotante. Como resultado, Cyrix ha decidido poner énfasis en el ``paralelismo'' a la hora de diseñar el procesador 6x86 para acelerar los programas que entremezclan estos dos tipos de instrucciones.
El modelo de exclusión de la unidad de coma flotante de los x86 permite la resolución de instrucciones con enteros mientras se ejecuta una instrucción en coma flotante. Por contra, no se puede ejecutar una segunda instrucción en coma flotante si ya se estaba ejecutando anteriormente una. Para eliminar la limitación en el rendimiento creada por el modelo de exclusión de la unidad de coma flotante, el procesador 6x86 puede realizar especulativamente hasta cuatro instrucciones en coma flotante al chip FPU mientras sigue ejecutando instrucciones enteras. Por ejemplo, en una secuencia de código con dos instrucciones en coma flotante (FLTs) seguidas por seis instrucciones enteras (INTs) y seguidas por dos FLTs más, el procesador 6x86 puede mandar las diez instrucciones anteriores a las unidades de ejecución apropiadas antes de que se termine la primera FLT. Si ninguna de las instrucciones falla (el caso típico), la ejecución continua con las unidades de enteros y de coma flotante terminando las instrucciones en paralelo. Si una de las FLTs falla (el caso atípico), la capacidad de ejecución especulativa del 6x86 permite que se restaure el estado del procesador de forma que sea compatible con el modelo de exclusión de la unidad de coma flotante del x86.
Un examen de los test de rendimiento revela que los test sintéticos de la unidad de coma flotante utiliza un código con solo operaciones de coma flotante, que no es lo que nos encontramos en las aplicaciones del mundo real. Este tipo de tests no aprovecha la capacidad de ejecución especulativa presente en el procesador 6x86. Cyrix cree que las pruebas que utilizan herramientas no sintéticas, basadas en aplicaciones del mundo real pueden reflejar mejor el rendimiento actual que pueden obtener los usuarios. Las aplicaciones del mundo real contienen instrucciones mezcladas de enteros y de coma flotante y utilizan por tanto, la capacidad de ejecución especulativa del 6x86.''

Por lo tanto, la tendencia en los tests de rendimiento es elegir las aplicaciones más comunes y utilizarlas para medir el rendimiento del sistema completo. Por ejemplo, SPEC, la organización sin ánimo de lucro que diseño las herramientas SPECINT y SPECFP, ha lanzado un proyecto para un nuevo conjunto de herramientas basadas en aplicaciones. Pero de nuevo, sería muy raro que alguna herramienta comercial de medida del rendimiento incluya código Linux.

Resumiendo, los tests sintéticos son válidos mientras comprenda sus propósitos y limitaciones. Las herramientas basadas en aplicaciones reflejarán mejor el rendimiento global del sistema, pero no hay ninguna disponible para Linux.

Tests de alto nivel vs. test de bajo nivel

Los tests de bajo nivel miden directamente el rendimiento de los componentes: el reloj de la CPU, los tiempos de la DRAM y de la caché SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio de pista, etc... ésto puede ser util en caso de comprar un sistema y no se saber con que componentes viene, pero una forma mejor de comprobar estos datos es abrir la caja, hacer un listado con los nombres que pueda conseguir y obtener una hoja de características de cada componente encontrado (normalmente disponibles en la red).

Otro uso de los tests de bajo nivel es comprobar que un controlador de núcleo ha sido correctamente instalado para un componente específico: si tiene la hoja de especificaciones del componente, puede comparar los resultados del test de bajo nivel con las especificaciones teóricas (las impresas).

Los tests de alto nivel están más enfocados a medir el rendimiento de la combinación componente/controlador/SO de un aspecto específico del sistema, como por ejemplo el rendimiento de E/S con ficheros, o el rendimiento de una determinada combinación de componentes/controlador/SO/aplicación, p.e. un test Apache en diferentes sistemas.

Por supuesto, todos los tests de bajo nivel son sintéticos. Los tests de alto nivel pueden ser sintéticos o de aplicación.

2.2 Tests estándares disponibles para Linux

EMMO un test sencillo que cualquiera puede hacer cuando actualiza cualquier componente en su Linux es hacer una compilación del núcleo antes y después de la actualización del componente o del programa y comparar los tiempos de compilación. Si todas las demás combinaciones se mantienen igual, entonces el test es válido como medida del rendimiento en la compilación, y uno ya puede decir que:

"Cambiar de A a B lleva a una mejora de un x % en el tiempo de compilación del núcleo de Linux bajo éstas y éstas condiciones".

¡Ni más, ni menos!

Ya que la compilación del núcleo es una tarea muy normal en Linux, y ya que ejercita muchas de las funciones que se realizan normalmente en los tests (excepto el rendimiento con las instrucciones en coma flotante), podemos concluir que es un test individual bastante bueno. Sin embargo en muchos casos, los resultados de un test no puede reproducirse por otros usuarios Linux debido a las variaciones en la configuración de los programas/componentes y por tanto este tipo de pruebas no puede utilizarse como ``vara de medida'' para comparar distintos sistemas (a menos que nos pongamos todos de acuerdo en compilar un núcleo estándar - ver más adelante).

Desgraciadamente, no hay herramientas de medida del rendimiento específicas para Linux, exceptuando el Byte Linux Benchmarks, que son una versión modificada del The Byte Unix Benchmarks que data de Mayo de 1991 (los módulos de Linux se deben a Jon Tombs, autores originales Ben Smith, Rick Grehan y Tom Yager).

Hay una página central para el Byte Linux Benchmarks.

David C. Niemi puso por ahí una versión del Byte Unix Benchmarks mejorada y actualizada. Para evitar confusiones con alguna versión anterior la llamó UnixBench 4.01. Aquí está lo que David escribió sobre sus modificaciones:

``La versión original y las versiones ligeramente modificadas de BYTE Unix Benchmarks se diferencian en varias cosas que los hacen ser un indicador inusualmente poco fiable del rendimiento del sistema. He hecho que los valores de mis ``índices'' parezcan muy diferentes para evitar confusiones con el viejo test.''

David ha creado una lista de correo majordomo para la discusión sobre las pruebas de rendimiento para Linux y para el resto de SOs. Puede unirse a la lista enviando un mensaje a majordomo@wauug.erols.com escribiendo en el cuerpo del mismo ``subscribe bench''. El Grupo de Usuarios de Unix del Area de Washington está en proceso de crear una página Web sobre los test de rendimiento en Linux.

También recientemente, Uwe F. Mayer, mayer@math.vanderbilt.edu portó el conjunto de pruebas Byte Bytemark a Linux. Éste es un moderno conjunto de herramientas que Rick Grehan envió a BYTE Magazine para comprobar la CPU, FPU y el rendimiento del sistema de memoria de los modernos sistemas de microordenador (hay pruebas estrictamente orientadas al rendimiento del procesador, sin tener en cuenta el rendimiento de la E/S o del sistema).

Uwe también ha creado una página Web con una base de datos de los resultados de las pruebas de su versión del Linux BYTEmark benchmarks.

Si busca pruebas sintéticas para Linux, en sunsite.unc.edu podrá encontrar unas cuantas. Para comprobar la velocidad relativa de los servidores X y de las tarjetas gráficas, el conjunto de herramientas xbench-0.2 creado por Claus Gittinger está disponible en sunsite.unc.edu, ftp.x.org y otros lugares. Xfree86.org rechaza (prudentemente) el llevar o recomendar ninguna prueba.

El XFree86-benchmarks Survey es una página Web con una base de datos de los resultados de x-bench.

Para el intercambio de E/S de disco, el programa hdparm (incluido con muchas distribuciones, si no lo tiene puede encontrarlo en sunsite.unc.edu) puede medir los ratios de transferencia si lo invoca con las opciones -t y -T.

Hay muchas otras herramientas disponibles de forma libre en Internet para comprobar varios aspectos del rendimiento de su Linux.

2.3 Enlaces y referencias

El comp.benchmarks.faq creado por Dave Sill es la referencia estándar en las pruebas de rendimiento. No es específico de Linux, pero es una lectura recomendada para cualquiera que se quiera ver seriamente implicado en las pruebas de rendimiento. Está disponible en muchos FTPs y páginas Web y muestra 56 pruebas diferentes, con enlaces a direcciones FTP o páginas Web donde se pueden recoger. Algunas de las pruebas que se mencionan son comerciales (SPEC, por ejemplo).

No voy a nombrar todos y cada uno de los tests que se mencionan en comp.benchmarks.faq, pero hay al menos una prueba de bajo nivel que me gustaría comentar: la prueba lmbench, de Larry McVoy. Citando a David C. Niemi:

``Linus y David Miller la utilizan mucho ya que es capaz de realizar útiles medidas de bajo nivel y también puede medir el trasvase y la latencia de la red si tiene dos ordenadores para hacer los tests. Pero no intenta conseguir algo así como un general ``rendimiento del sistema''...''

Un lugar FTP bastante completo en cuanto a utilidades libres de medida del rendimiento puesto en marcha por Alfred Aburto. Las herramientas Whetstone utilizadas en el LBT se encontraron aquí.

También tenemos el FAQ multiparte de Eugene Miya que deja regularmente en comp.benchmarks; es una referencia excelente.

3. El Linux Benchmarking Toolkit (LBT)

Quiero proponer un conjunto básico de herramientas de medida para Linux. Es sólo una versión preliminar de un general Linux Benchmarking Toolkit, que será expandido y mejorado. Tómelo como lo que es, i.e. como una propuesta. Si no cree que es un conjunto de herramientas válido, sientase libre de enviarme un correo electrónico con sus críticas y estaré encantado de hacer los cambios y mejoras, si puedo. Sin embargo, antes de tomar una decisión, lea este CÓMO y las referencias mencionadas: las críticas informadas serán bienvenidas, las críticas sin fundamento no.

3.1 Bases lógicas

Ésto es sólo de sentido común:

  1. No debe llevar un día el ejecutarlo. Cuando hay que hacer tests comparativos (varias ejecuciones), no hay nadie que esté dispuesto a pasar días tratando de averiguar la mejor configuración de un sistema. Idealmente, el conjunto completo de pruebas debe llevar unos 15 minutos en una máquina media.
  2. Todo el código fuente de los programas de estar libremente disponible en la Red, por razones obvias.
  3. Los tests deben proporcionar una representación sencilla de los resultados que refleje el rendimiento medido.
  4. Debe haber una mezcla de tests sintéticos y de tests de aplicación (con resultados separados, por supuesto).
  5. Cada test sintético debe ejercitar un subsistema particular hasta su máxima capacidad.
  6. Los resultados de los tests sintéticos NO deben mezclarse en un sólo resultado general (ésto acaba con la toda la idea que hay detrás de los tests sintéticos, con una considerable pérdida de información).
  7. Los tests de aplicación deben consistir en tareas usualmente ejecutadas en los sistemas Linux.

3.2 Selección de herramientas

He seleccionada cinco conjuntos de herramientas, tratando de evitar, en la medida de lo posible, el solapamiento de pruebas. Son éstas:

  1. Compilación del Núcleo 2.0.0 (con la configuración por defecto) utilizando gcc.
  2. La versión 10/03/97 de Whetstone (la última que ha sacado Roy Longbottom).
  3. xbench-0.2 (con los parámetros de ejecución rápida).
  4. La versión 4.01 de UnixBench (resultados parciales).
  5. La distribución 2 de la versión beta de los test BYTEmark de la revista BYTE Magazine (resultados parciales).

Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se tendrán en cuenta todos los resultados producidos por estos tests.

3.3 Duración de las pruebas

  1. Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del rendimiento real de su sistema.
  2. Whetstone: 100 segundos.
  3. Xbench-0.2: < 1 hora.
  4. Versión 4.01 de los tests UnixBench: aprox. 15 minutos.
  5. Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos.

3.4 Comentarios

Compilación del Núcleo 2.0.0:

Whetstone:

Xbench-0.2:

UnixBench version 4.01:

BYTE Magazine's BYTEmark benchmarks:

3.5 Possible improvements

The ideal benchmark suite would run in a few minutes, with synthetic benchmarks testing every subsystem separately and applications benchmarks providing results for different applications. It would also automatically generate a complete report and eventually email the report to a central database on the Web.

We are not really interested in portability here, but it should at least run on all recent (> 2.0.0) versions and flavours (i386, Alpha, Sparc...) of Linux.

If anybody has any idea about benchmarking network performance in a simple, easy and reliable way, with a short (less than 30 minutes to setup and run) test, please contact me.

3.6 LBT Report Form

Besides the tests, the benchmarking procedure would not be complete without a form describing the setup, so here it is (following the guidelines from comp.benchmarks.faq):


LINUX BENCHMARKING TOOLKIT REPORT FORM


CPU 
== 
Vendor: 
Model: 
Core clock: 
Motherboard vendor: 
Mbd. model: 
Mbd. chipset: 
Bus type: 
Bus clock: 
Cache total: 
Cache type/speed: 
SMP (number of processors): 


RAM 
==== 
Total: 
Type: 
Speed: 


Disk 
==== 
Vendor: 
Model: 
Size: 
Interface: 
Driver/Settings: 


Video board 
=========== 
Vendor: 
Model: 
Bus:
Video RAM type: 
Video RAM total: 
X server vendor: 
X server version: 
X server chipset choice: 
Resolution/vert. refresh rate: 
Color depth: 


Kernel 
===== 
Version: 
Swap size:


gcc 
=== 
Version: 
Options: 
libc version: 


Test notes 
==========


RESULTS 
======== 
Linux kernel 2.0.0 Compilation Time: (minutes and seconds) 
Whetstones: results are in MWIPS. 
Xbench: results are in xstones. 
Unixbench Benchmarks 4.01 system INDEX:  
BYTEmark integer INDEX:
BYTEmark memory INDEX:


Comments* 
========= 
* This field is included for possible interpretations of the results, and as 
such, it is optional. It could be the most significant part of your report, 
though, specially if you are doing comparative benchmarking. 

3.7 Network performance tests

Testing network performance is a challenging task since it involves at least two machines, a server and a client machine, hence twice the time to setup and many more variables to control, etc... On an ethernet network, I guess your best bet would be the ttcp package. (to be expanded)

3.8 SMP tests

SMP tests are another challenge, and any benchmark specifically designed for SMP testing will have a hard time proving itself valid in real-life settings, since algorithms that can take advantage of SMP are hard to come by. It seems later versions of the Linux kernel (> 2.1.30 or around that) will do "fine-grained" multiprocessing, but I have no more information than that for the moment.

According to David Niemi, " ... shell8 [part of the Unixbench 4.01 benchmaks]does a good job at comparing similar hardware/OS in SMP and UP modes."

4. Example run and results

The LBT was run on my home machine, a Pentium-class Linux box that I put together myself and that I used to write this HOWTO. Here is the LBT Report Form for this system:

LINUX BENCHMARKING TOOLKIT REPORT FORM
CPU 
== 
Vendor: Cyrix/IBM 
Model: 6x86L P166+
Core clock: 133 MHz
Motherboard vendor: Elite Computer Systems (ECS)
Mbd. model: P5VX-Be
Mbd. chipset: Intel VX
Bus type: PCI
Bus clock: 33 MHz
Cache total: 256 KB
Cache type/speed: Pipeline burst 6 ns
SMP (number of processors): 1
RAM 
==== 
Total: 32 MB
Type: EDO SIMMs
Speed: 60 ns
Disk 
==== 
Vendor: IBM
Model: IBM-DAQA-33240
Size: 3.2 GB
Interface: EIDE
Driver/Settings: Bus Master DMA mode 2
Video board 
=========== 
Vendor: Generic S3
Model: Trio64-V2
Bus: PCI
Video RAM type: EDO DRAM 
Video RAM total: 2 MB
X server vendor: XFree86
X server version: 3.3
X server chipset choice: S3 accelerated 
Resolution/vert. refresh rate: 1152x864 @ 70 Hz
Color depth: 16 bits
Kernel 
===== 
Version: 2.0.29
Swap size: 64 MB
gcc 
=== 
Version: 2.7.2.1
Options: -O2
libc version: 5.4.23 
Test notes 
==========
Very light load. The above tests were run with some of the special 
Cyrix/IBM 6x86 features enabled with the setx86 program: fast ADS, 
fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem.
RESULTS 
======== 
Linux kernel 2.0.0 Compilation Time: 7m12s
Whetstones: 38.169 MWIPS. 
Xbench: 97243 xStones. 
BYTE Unix Benchmarks 4.01 system INDEX: 58.43
BYTEmark integer INDEX: 1.50
BYTEmark memory INDEX: 2.50
Comments
========= 
This is a very stable system with homogeneous performance, ideal 
for home use and/or Linux development. I will report results 
with a 6x86MX processor as soon as I can get my hands on one!

5. Pitfalls and caveats of benchmarking

After putting together this HOWTO I began to understand why the words "pitfalls" and "caveats" are so often associated with benchmarking...

5.1 Comparing apples and oranges

Or should I say Apples and PCs ? This is so obvious and such an old dispute that I won't go into any details. I doubt the time it takes to load Word on a Mac compared to an average Pentium is a real measure of anything. Likewise booting Linux and Windows NT, etc... Try as much as possible to compare identical machines with a single modification.

5.2 Incomplete information

A single example will illustrate this very common mistake. One often reads in comp.os.linux.hardware the following or similar statement: "I just plugged in processor XYZ running at nnn MHz and now compiling the linux kernel only takes i minutes" (adjust XYZ, nnn and i as required). This is irritating, because no other information is given, i.e. we don't even know the amount of RAM, size of swap, other tasks running simultaneously, kernel version, modules selected, hard disk type, gcc version, etc... I recommend you use the LBT Report Form, which at least provides a standard information framework.

5.3 Proprietary hardware/software

A well-known processor manufacturer once published results of benchmarks produced by a special, customized version of gcc. Ethical considerations apart, those results were meaningless, since 100% of the Linux community would go on using the standard version of gcc. The same goes for proprietary hardware. Benchmarking is much more useful when it deals with off-the-shelf hardware and free (in the GNU/GPL sense) software.

5.4 Relevance

We are talking Linux, right ? So we should forget about benchmarks produced on other operating systems (this is a special case of the "Comparing apples and oranges" pitfall above). Also, if one is going to benchmark Web server performance, do not quote FPU performance and other irrelevant information. In such cases, less is more. Also, you do not need to mention the age of your cat, your mood while benchmarking, etc..

6. FAQ

Q1.

Is there any single figure of merit for Linux systems ?

A:

No, thankfully nobody has yet come up with a Lhinuxstone (tm) measurement. And if there was one, it would not make much sense: Linux systems are used for many different tasks, from heavily loaded Web servers to graphics workstations for individual use. No single figure of merit can describe the performance of a Linux system under such different situations.

Q2.

Then, how about a dozen figures summarizing the performance of diverse Linux systems ?

A:

That would be the ideal situation. I would like to see that come true. Anybody volunteers for a Linux Benchmarking Project ? With a Web site and an on-line, complete, well-designed reports database ?

Q3.

... BogoMips ... ?

A:

BogoMips has nothing to do with the performance of your system. Check the BogoMips Mini-HOWTO.

Q4.

What is the "best" benchmark for Linux ?

A:

It all depends on which performance aspect of a Linux system one wants to measure. There are different benchmarks to measure the network (Ethernet sustained transfer rates), file server (NFS), disk I/O, FPU, integer, graphics, 3D, processor-memory bandwidth, CAD performance, transaction time, SQL performance, Web server performance, real-time performance, CD-ROM performance, Quake performance (!), etc ... AFAIK no bechmark suite exists for Linux that supports all these tests.

Q5.

What is the fastest processor under Linux ?

A:

Fastest at what task ? If one is heavily number-crunching oriented, a very high clock rate Alpha (600 MHz and going) should be faster than anything else, since Alphas have been designed for that kind of performance. If, on the other hand, one wants to put together a very fast news server, it is probable that the choice of a fast hard disk subsystem and lots of RAM will result in higher performance improvements than a change of processor, for the same amount of $.

Q6.

Let me rephrase the last question, then: is there a processor that is fastest for general purpose applications ?

A:

This is a tricky question but it takes a very simple answer: NO. One can always design a faster system even for general purpose applications, independent of the processor. Usually, all other things being equal, higher clock rates will result in higher performance systems (and more headaches too). Taking out an old 100 MHz Pentium from an (usually not) upgradable motherboard, and plugging in the 200 MHz version, one should feel the extra "hummph". Of course, with only 16 MBytes of RAM, the same investment would have been more wisely spent on extra SIMMs...

Q7.

So clock rates influence the performance of a system ?

A:

For most tasks except for NOP empty loops (BTW these get removed by modern optimizing compilers), an increase in clock rate will not give you a linear increase in performance. Very small processor intensive programs that will fit entirely in the primary cache inside the processor (the L1 cache, usually 8 or 16 K) will have a performance increase equivalent to the clock rate increase, but most "true" programs are much larger than that, have loops that do not fit in the L1 cache, share the L2 (external) cache with other processes, depend on external components and will give much smaller performance increases. This is because the L1 cache runs at the same clock rate as the processor, whereas most L2 caches and all other subsystems (DRAM, for example) will run asynchronously at lower clock rates.

Q8.

OK, then, one last question on that matter: which is the processor with the best price/performance ratio for general purpose Linux use ?

A:

Defining "general purpose Linux use" in not an easy thing ! For any particular application, there is always a processor with THE BEST price/performance ratio at any given time, but it changes rather frequently as manufacturers release new processors, so answering Processor XYZ running at n MHz would be a snapshot answer. However, the price of the processor is insignificant when compared to the price of the whole system one will be putting together. So, really, the question should be how can one maximize the price/performance ratio for a given system ? And the answer to that question depends heavily on the minimum performance requirements and/or maximum cost established for the configuration being considered. Sometimes, off-the-shelf hardware will not meet minimum performance requirements and expensive RISC systems will be the only alternative. For home use, I recommend a balanced, homogeneous system for overall performance (now go figure what I mean by balanced and homogeneous :-); the choice of a processor is an important decision , but no more than choosing hard disk type and capacity, amount of RAM, video card, etc...

Q9.

What is a "significant" increase in performance ?

A:

I would say that anything under 1% is not significant (could be described as "marginal"). We, humans, will hardly perceive the difference between two systems with a 5 % difference in response time. Of course some hard-core benchmarkers are not humans and will tell you that, when comparing systems with 65.9 and 66.5 performance indexes, the later is "definitely faster".

Q10.

How do I obtain "significant" increases in performance at the lowest cost ?

A:

Since most source code is available for Linux, careful examination and algorithmic redesign of key subroutines could yield order-of-magnitude increases in performance in some cases. If one is dealing with a commercial project and does not wish to delve deeply in C source code a Linux consultant should be called in. See the Consultants-HOWTO.

7. Copyright, acknowledgments and miscellaneous

7.1 How this document was produced

The first step was reading section 4 "Writing and submitting a HOWTO" of the HOWTO Index by Greg Hankins.

I knew absolutely nothing about SGML or LaTeX, but was tempted to use an automated documentation generation package after reading the various comments about SGML-Tools. However, inserting tags manually in a document reminds me of the days I hand-assembled a 512 byte monitor program for a now defunct 8-bit microprocessor, so I got hold of the LyX sources, compiled it, and used its LinuxDoc mode. Highly recommended combination: LyX and SGML-Tools.

7.2 Copyright

The Linux Benchmarking HOWTO is copyright (C) 1997 by André D. Balsa. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below.

In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.

If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator, at gregh@sunsite.unc.edu via email, or at +1 404 853 9989.

7.3 New versions of this document

New versions of the Linux Benchmarking-HOWTO will be placed on sunsite.unc.edu and mirror sites. There are other formats, such as a Postscript and dvi version in the other-formats directory. The Linux Benchmarking-HOWTO is also available for WWW clients such as Grail, a Web browser written in Python. It will also be posted regularly to comp.os.linux.answers.

7.4 Feedback

Suggestions, corrections, additions wanted. Contributors wanted and acknowledged. Flames not wanted.

I can always be reached at andrewbalsa@usa.net.

7.5 Acknowledgments

David Niemi, the author of the Unixbench suite, has proved to be an endless source of information and (valid) criticism.

I also want to thank Greg Hankins, the Linux HOWTO coordinator and one of the main contributors to the SGML-tools package, Linus Torvalds and the entire Linux community. This HOWTO is my way of giving back.

7.6 Disclaimer

Your mileage may, and will, vary. Be aware that benchmarking is a touchy subject and a great time-and-energy consuming activity.

7.7 Trademarks

Pentium and Windows NT are trademarks of Intel and Microsoft Corporations respectively.

BYTE and BYTEmark are trademarks of McGraw-Hill, Inc.

Cyrix and 6x86 are trademarks of Cyrix Corporation.

Linux is not a trademark, hopefully never will be.